Re: CIMD 2.0 & Greek
Alexander Malysh <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel,gmane.comp.mobile.kannel.user |
|---|---|
| Message-ID | <[email protected]> |
Hi,
this patch is really a kludge and so -1 from me.
As to leave smsc module with GSM0338 that is also wrong. Message body
should leave smsc module in UTF8 so than we can handle every charset.
User then should be responsible to convert it some other charset if
needed or maybe smsbox could do this for him.
Thanks,
Alex
Stipe Tolj schrieb:
> Thanos Chatziathanassiou wrote:
>
>> Stipe Tolj wrote:
>>
>>> Thanos Chatziathanassiou wrote:
>>>
>>>> --- charset.c.orig Thu Jan 22 16:08:24 2004
>>>> +++ charset.c Mon Feb 27 12:23:49 2006
>>>> @@ -76,11 +76,15 @@
>>>> * The escape character, at position 27, is mapped to a space,
>>>> * though normally the function that indexes into this table will
>>>> * treat it specially. */
>>>> +
>>>> +/* patched for greek chars already present in GSM 7bit
>>>> + (chars 0x10,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1a) */
>>>> +
>>>> static const unsigned char gsm_to_latin1[128] = {
>>>> '@', 0xa3, '$', 0xa5, 0xe8, 0xe9, 0xf9, 0xec, /* 0 - 7 */
>>>> 0xf2, 0xc7, 10, 0xd8, 0xf8, 13, 0xc5, 0xe5, /* 8 - 15 */
>>>> - '?', '_', '?', '?', '?', '?', '?', '?', /* 16 - 23 */
>>>> - '?', '?', '?', ' ', 0xc6, 0xe6, 0xdf, 0xc9, /* 24 -
>>>> 31 */
>>>> + 0x10, '_', 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, /* 16 - 23 */
>>>> + 0x18, 0x19, 0x1a, ' ', 0xc6, 0xe6, 0xdf, 0xc9, /* 24 -
>>>> 31 */
>>>> ' ', '!', '"', '#', 0xa4, '%', '&', '\'', /* 32 - 39 */
>>>> '(', ')', '*', '+', ',', '-', '.', '/', /* 40 - 47 */
>>>> '0', '1', '2', '3', '4', '5', '6', '7', /* 48 - 55 */
>>>
>>>
>>> this patch is "works" if you punch in the greek values of GSM 03.38
>>> alphabet in there. But remember(!), they are not part of ISO-8859-1
>>> (latin1), they are part of latin7. So this patch is a kludge.
>>
>> Yes, it is...but then again so is GSM 03.38 :)
>>
>>> We obviously "loose" characters (those marked with '?') when mapping
>>> from GSM default alphabet to latin1. We should use UTF-8 (unicode)
>>> instead?!
>>
>> We could, but we'd be giving up on 160-chars-long SMS. Besides, some
>> (admittedly old) devices don't handle utf8 all too well...
>>
>> If I understand correctly, your problem is that this isn't
>> ``gsm_to_latin1'' any more. Maybe we could translate to/from
>> iso-8859-7 for these chars. i.e. 0x10 would become 0xC4 which is greek
>> capital delta on iso-8859-7.
>> Thing is, my end application (and probably Kyriakos' too) was already
>> prepared to handle this, so I simply didn't bother. If we're talking
>> about integrating it properly to kannel, I think that's the best way
>> to go. Maybe even have it as a configuration option.
>> That would only leave a problem with the Euro sign (double-byte 0x1B
>> 0x65).
>>
>> Thoughts ?
>
> [I'll move this thread to devel@ list, since it's more appropriate there]
>
> yep, correct. This "should" be configurable. Actually we do may
> gsm_to_latin1() already _inside_ the smsc modules. Which seems "wrong"
> to me. We should exit the smsc-specific layer with GSM default charset,
> and allow the user to change the exit charset encoding in the abstaction
> layer. Which would mean this has to be done only in one global place for
> all smsc modules.
>
> Alex, your thoughts on this?
> Others?
>
> Stipe
>
> -------------------------------------------------------------------
> Kölner Landstrasse 419
> 40589 Düsseldorf, NRW, Germany
>
> tolj.org system architecture Kannel Software Foundation (KSF)
> http://www.tolj.org/ http://www.kannel.org/
>
> mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
> -------------------------------------------------------------------
>
>