Re: Emojifix (iOS/Android Emoji SMS fix)
 

Yes, indeed I haven't thought about the sending Emoji SMS path. hedayat's fix (replacing all occurences of UCS-2 with UTF16) probably fixed that as a side effect, so to fix that in my solution, there needs to be a code updated as suggested by peterleinchen:

https://github.com/thp/emojifix/comm...d6306343645f39

I'll try to update the binaries (updated libxconv library) soon.

If anybody feels motivated, one could update the patcher to find the string table in the ELF file and replace "UCS-2" with "UTF16" (hedayat's solution):

https://github.com/thp/emojifix/blob.../src/patcher.c

Of course, the easier way in that case would just be using on the .so ;)

Re: Emojifix (iOS/Android Emoji SMS fix)
 

New binary build now available here:

http://thp.io/2014/emojifix/emojifix...5-07-09.tar.gz

To reproduce this build from source, just build it in the Harmattan SDK:

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Just one question: I was going to use 'sed', but I was unsure if it'll work on binary files (specially since it is line based). Is using sed safe? If it is, that'll be great. :)

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Hooray,
just sent a SMS with an iPhone emoticon -that did not work before- from N900 to N9 (and vice versa with some added harmoji 0.6.6)! :D

Thanks thp (and hedayat).

--edit
just one (maybe) negative thing now:
the char counter is f*#cked up
on N900 it goes immediately from 160 to 67 after inserting an emoticon (which is pretty normal)
and/but also jumps from 160 to 68 on inserting a normal character
--edit
and goes back to 158 after inserting second ASCII character. So, as I assume, no one will send a one-char SMS all good on N900

on N9 the counter goes to zero on inserting an emoticon

no idea whether those counters are reliable now (possibly using utf16 'eats' resources, 92 chars????)

Re: Emojifix (iOS/Android Emoji SMS fix)
 

using sed on binary should also work (content is one big line?)
but I am not sure if thp's command
will work. Exchanging (hex editing) a binary and changing lengths is dangerous. Possibly he meant
But just go ahead and try 😜

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Using sed on a binary will work; and yes, shouldn't change the string size then, as all offsets after it would become invalid; updated my post accordingly.

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Jumping from 160 to 67 is normal when you type non-ASCII (e.g. Persian) SMSes (not related to Emoji's), so that's correct. But it should not happen if you write ASCII SMSes; and the counter should jump back to x/160 state rather than x/67.

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Not sure if there's anything additional to SMS encoding (each part in a multi-SMS gets less space than a single non-multi-SMS), but in general for UCS-2 vs UTF-16:

UCS-2 can only encode codepoints between 0 and 2^16 (that's the reason why some Emoji characters outside of this range don't work). Each character takes up 16 bits (2 bytes). UCS-2 is defined as big endian, so usually no byte order mark is necessary(?).

UTF-16 can encode all unicode codepoints, using either 16 bits (2 bytes) if it fits, or 32 bits (4 bytes) otherwise. UTF-16 can be big endian and little endian, so a byte order mark might be necessary (not sure if the endianness is defined for SMS and UTF-16/UCS-2).

The README file contains some links to SMS encoding webpages related to UTF-16/UCS-2.

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Will this fix go to CSSU testing?

Re: Emojifix (iOS/Android Emoji SMS fix)
 

Unfortunately MeeGo/Harmattan has no CSSU! ;)

But definitely worth to be integrated into Maemo/N900 CSSU.
As it is fix for Nokia blob, it probably will end up as patcher utility deb. But this will be decision of maintainer.
We (you?) should contact CSSU maintainer...