Hi,
2010/9/3 Pekka Pessi <ppessi(a)gmail.com>:
Morjes Aki,
2010/9/2 Aki Niemi <aki.niemi(a)nokia.com>:
> + case SMS_ALPHABET_TURKISH:
> + gsm_encoded = convert_utf8_to_gsm_with_lang(utf8, -1, NULL,
> + &written, 0,
> + GSM_DIALECT_TURKISH,
> + GSM_DIALECT_TURKISH);
If you look at the tables, the idea is normally to use either locking
Turkish and default single, or default locking and Turkish single
shift, never both.
I suppose I should've looked at the tables, then.
Anyway, the best way to use the dialects would obviously be to find
the optimal encoding, and use as few extension tables as possible.
That is missing currently.
Also, if it is possible to fit the message to one segment only using
national single shift table, single shift should be used (if receiver
does not support national variants, the result is much less garbled).
Sure, you could even try any combination of dialects to find the
optimal encoding.
If you look at the Turkish tables, they try to align with the default
tables. That is, if the recipient doesn't understand the extensions,
they will use a rather similar looking character from the default
table.
That principle is gone with Portuguese and later extensions.
I just peeked in the 23.038 from release 9, it seems to me that we
are
bound to get much more entertainment.
The funny thing is that the new tables seem to pack a lot of new
characters into single shift. Which compared with UCS-2, is of course
only 2bits per character more efficient.
Cheers,
Aki