LCDproc development and user support list

Text archives Help


[Lcdproc] UTF8 support


Chronological Thread 
  • From: brabant AT magma.ca (Mathieu Brabant)
  • Subject: [Lcdproc] UTF8 support
  • Date: Mon Apr 28 04:45:03 2008

Well, the server side is ~90% done. All I have left to do is modify the=20
menu.c and menuitem.c to work with UTF.

UTF8 strings received from clients and internal server messages are being=20
converted to UTF32 and passed as such to the driver's 'string' and 'chr'=20
functions.

I added a UTF.c and UTF.h into the shared folder. I had to write versions =
of=20
strlen, strncpy and strncat compatible with UTF32.

All I had to do to get the driver I'm using (imonlcd) to work is change the=
=20
data type for the string and chr function from char to UTF32 (a typedef of=
=20
32bit). Internally this driver uses a 6x8 pixel-based font definition with=
a=20
32 bit index, so it was very easy to get it to work. We can add a new=20
unicode character to it's index with a simple line :

{ 0x00E9, { 0x00, 0x1C, 0x2A, 0x6A, 0xAA, 0x18 } }, // Code point U+00E9 -=
> =E9

I haven't looked at the other drivers yet... :-s

If any body want patches let me know...

Mathieu


On Sunday 27 April 2008 10:06:00 am Mathieu Brabant wrote:
> Yes, it would have to be specified in the protocol but I think most clien=
ts
> already support UTF8 if they are running in an UTF8 environment, nothing
> would have to change client-wise. If a client does not run in a UTF8
> environment, they will still work if they use chars < 0x7F (plain old
> ASCII), that's the beauty of UTF8.
>
> The biggest pain will be to modify all the drivers so they work by
> accepting UTF32 strings. Hopefully modifying the data type inside each
> driver will be enough so they at least support <0x7F ASCII chars without
> breaking. The drivers development guide would definitely have to be
> updated.
>
> I know the code to the imonlcd driver pretty well (from Dean @ codeka.com,
> not yet in CVS) and would be able to get it working for UTF32 with chars >
> 0x7F, but I'm not sure I want to modify all the 59 other drivers so they
> properly render chars > 0x7F.
>
> I quickly looked at more code and I think the conversion from UTF8 to UTF=
32
> would happen in widget_set_func (widget_commands.c), when the client
> command is processed for setting widget properties.
>
> Who are the active developpers ? How would I go about submitting the
> patches to accomplish this ?
>
>
> Mathieu
>
> On Sunday 27 April 2008 05:12:32 am Anders Eriksson wrote:
> > brabant AT magma.ca
> > said:
> > > Any opinions ?
> >
> > I'd much appreciate lcdproc doing utf8. Thanks for looking into this.
> >
> > Wouldn't this require a protocol (version) change (as the current
> > protocol doesn't indicate the charset for the text)?
> >
> > If so, there's a bunch or other issues with the protocol which we might
> > want to address while at it.
> >
> > /A





Archive powered by MHonArc 2.6.18.

Top of page