Re: non-ASCII character support in the nk6110

[Pawel Kot]

On Tue, 12 Nov 2002, BORBELY Zoltan wrote:

Hi Bozo,

I have reread our January conversation, and I think I changed my
opinion a bit ;-) See below.

> As you know the ETSI character set contains only a limited set of characters
> from the ISO-8859-2 table. The 6110 (and maybe other compatible phones too
> where you can store phonebook entries on the phone [1]) extends the ETSI
> character set. I implemented an experimental support for these characters.
> Only the the hungarian characters supported currently, but others can be added
> to the table too. The patch is applied to the CVS. It will break only the "AE"
> character (the A' "LATIN CAPTAL LETTER A WITH ACUTE" character uses this code
> too -- blame nokia).

In one, I think, we agree -- we should use unicode as the internal storage
format. At least we did at irc.

Now there's a second thing: default GSM alphabet and Nokia's extention
for 6100 series. I hope we agree here: these two things should be
separated. Think at least of the AT phones.

Let's talk now about GSM alphabet. IMHO the encoding/decoding table is
good here. But:
 - we should use unicode table here,
 - we should use as small table here as possibe -- efficiency is not that
important -- we have only 127 characters :-) I don't think there exists
any application when the linear seach in 127-elements array is too slow.

Now we come to the Nokia extension. We have some, let's call them Nokia
values, that denote characters that are neither in the latin1 alphabet nor
in the default GSM alphabet. I think we can easily use the similiar tables
for them.

API we would need would more or less look like:
bool inDefaultAlphabet(int) -> true if the value can be converted to
                               latin1 with the default alphabet table
int encodeDefaultAlphabet(int) -> encodes character with default alphabet
                                  table, -1 if conversion is impossible
int decodeDefaultAlphabet(int) -> ...
bool isNokiaExtension(int)
int encodeNokiaExtension(int)
ine decodeNokiaExtension(int)
 these 3 are analogous to the former 3.

And as I said, all of them can use some internal tables (as it is now for
the default alphabet), but let's keep these tables as small as possible.

This implies that the final encoding and the initial encoding has to take
part in the phone driver -- but I don't think it is bad.

Does it make sense or do I need more sleep?

pkot
-- 
mailto:address@hidden :: mailto:address@hidden
http://kt.linuxnews.pl/ :: Kernel Traffic po polsku