[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Euro symbols show up as Currency symbols

From: Pawel Kot
Subject: Re: Euro symbols show up as Currency symbols
Date: Thu, 25 Jul 2002 01:15:41 +0200 (CEST)

On Wed, 24 Jul 2002, Sami Rosenblad wrote:

> On Wednesday, July 24, 2002, at 11:48 AM, Pawel Kot wrote:
> >>>> address@hidden 24 July 2002 10:32:21 >>>
> >> Consequently, gnokii thinks the character set is ISO-8859-1, not
> >> ISO-8859-15. How can I force this?
> >
> > You may try to use unicode. I'll look closer at this soon.
> Much appreciated. Using 'e' as a replacement for Euro in text messages
> is an ugly hack I'd like to get rid of. :)

OK. Should be done at the moment in CVS. Just issue:
echo "some text containing euro (\x0a4) character" | gnokii --sendsms 123456
There's also support for the whole GSM Default Alphabet Extension.
Unfortunatetly, as the euro has the same code as currency symbol, you
can't use the latter at the moment. AFAIK Bozo works now on converting the
internal gnokii structures into the unicode, which will solve this

> I tried unicode first, since the ChangeLog said that it's supported.
> This broke everything else, like 'ä', 'ö', and other high-bit Latin1
> chars.

Could you please be more specific? Or even send here the dumps of the
sms seinding tries? In fact you don't need to set your terminal to UTF-8.
You can simply use the characters that don't exist in the gsm default
alphabet. Such example are Polish characters (latin2, iso-8859-2).

> What flavour of Unicode exactly is supported? I realize that UTF-8 is
> but a subset of Unicode. Does gnokii understand the real Unicode Euro
> symbol at character position 8364 (hex 20AC)? Tried it out with:
> perl -e 'print "\x20\xac"' | gnokii --sendsms ...
> But this showed up as '???' on my Nokia 3330, which is capable of
> displaying the Euro symbol.

Yes. This is expected behaviour. Gnokii does not correctly treat input
data in the unicode format. (Or maybe it does when the utf locale is
set?). This is how it works:
1. Get the input data
2. Check whether the input data can be encoded with the default alphabet
2a. If so, send it as the default alphabet
3. Convert the input data to the unicode, accorting to the locale set
4. Send the text as unicode.

I don't expect that anything good may happen when the input is in unicode.
In the future it will look as follows:
1. Get the input data
2. Convert the input data to the unicode, according to the locale set
3. Check whether the input data can be enoded with the default alphabet
3a. If so, send it as the default alphabet
3b. If not, send it as the unicode

This require some work to be done, but it is not at the highest place on
my personal todo list.

mailto:address@hidden :: mailto:address@hidden :: Kernel Traffic po polsku

reply via email to

[Prev in Thread] Current Thread [Next in Thread]