Re: Internationalisation

This is a multi-part message in MIME format.
--===============0224458797300104742==
Content-Type: multipart/alternative;
 boundary="------------060201030202080901070309"

This is a multi-part message in MIME format.
--------------060201030202080901070309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hallo!
Am 06.03.2014 08:00, Markus Dolze wrote:
> Hi,
>
> character encoding - where should I begin?
>
> It is true that LCDd does not handle anything else than single byte
> characters as input from clients.
>
> However, it does not assume any encoding - other than it contains
> characters that can be parsed into commands.
>
> Any data is passed to the drivers 'as is'. Some drivers map that (single
> byte) characters to values in CGROM of the display. The Crystalfontz and
> HD4480 drivers e.g. assume ISO 8859-1 as input by default and can handle
> ISO 8859-5, CP-1251, KOI8-R as well.
The HD4480 driver is a special case. There are many HD4480-clones wit 
different character sets on the market. Some clones even have several 
switchable character sets build in.
>
> The picolcd driver does not do any character mapping.
>
>
> Currently I am fine with this, except the developer's guide does not
> talk about it. Clients are responsible for sending single byte
> characters to LCDd (whatever encoding).
>
> I am not agaist using UTF-8 as input. If we want to use it, my opinion
> is not to apply it to some 'widget text value', but to the whole input
> before it is parsed.
I would really appreciate UTF-8 as input character set.
My current solution is to run the entire computer at ISO 8859-1, but 
that causes issues with samba.

And yes, we should convert the whole input to a character set which is 
compatible with the display.
It doesn't make sense to apply the recoding only on parts of the input.
>
> By using libiconv we may get rid of mapping non ISO 8859-1 encoded input
> to CGROM values. Or not.
Yes I think so.
It's my understanding that, one put UTF-8 encoded data in and get ISO 
8859-1 encoded data out. (Or whatever encodings one want.)

But so far I only used the standalone program not the lib.
>
> However, auto-detecting the system locale only works if client and
> server run on the same system and share the same locale (which might not
> be true for LCDd started at boot time and a client that runs in a user
> session).
The display side is the easy one. Either the character set of the 
display is known or we use ISO 8859-1 until someone has a better 
matching suggestion.

On the client side one could use the locale of the server or a default 
character set (UTF-8 for example).
In my opinion every client should be able to set its character set 
individually. Because every client of a server could run in a different 
locale.
>
> Library dependencies and compatibility are another topic for some future
> discussion.
afaik iconv() is part of the GNU libc.||I don't see any mayor Problem there.

Regards
Stefan|
|
>
> Regards,
> Markus
>
>
> On 27.02.2014 21:47, Martin Tharby Jones wrote:
>> Hello,
>>
>> I've attached a patch which provides a first step towards
>> internationalisation of LCDproc.
>>
>> I'm a British English speaker with minimal second language skills so I
>> apologise that I have only addressed those areas that are relevant to
>> me. My problem was that I have a number of Celtic&   Gaelic tracks in
>> my music collection and the accented characters used in those
>> languages were not being displayed correctly.
>>
>> UTF-8 characters greater than 0x7F were displayed as two or more
>> strange characters:
>>
>>
>> With the patch and a display that supports ISO-8859-1 most western
>> European languages can be displayed:
>>
>>
>>
>> I've also added string support for Unicode on graphic displays:
>>
>>
>> I've not done title or scroller widgets because I feel graphic
>> displays should support pixel level scrolling and proportional spaced
>> fonts which would require more work than I am prepared for (I don't
>> have a graphic display). Basic string support was coded as proof of
>> concept and as a test case.
>>
>> There is obviously more to do but the code in the patch meets my
>> requirements and I hope will be of use to others.
>>
>> Further work I have thought of:
>>
>>    * Conversion of menu text
>>    * Use of gettext() and conversion for system screens
>>    * Use of gettext() and conversion for lcdproc screens
>>
>> Regards
>>
>> Martin
>
> _______________________________________________
> LCDproc mailing list
> [email protected]
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>


--------------060201030202080901070309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hallo!<br>
    Am 06.03.2014 08:00, Markus Dolze wrote:
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">Hi,

character encoding - where should I begin?

It is true that LCDd does not handle anything else than single byte
characters as input from clients.

However, it does not assume any encoding - other than it contains
characters that can be parsed into commands.

Any data is passed to the drivers 'as is'. Some drivers map that (single
byte) characters to values in CGROM of the display. The Crystalfontz and
HD4480 drivers e.g. assume ISO 8859-1 as input by default and can handle
ISO 8859-5, CP-1251, KOI8-R as well.</pre>
    </blockquote>
    The HD4480 driver is a special case. There are many HD4480-clones
    wit different character sets on the market. Some clones even have
    several switchable character sets build in. <br>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">

The picolcd driver does not do any character mapping.


Currently I am fine with this, except the developer's guide does not
talk about it. Clients are responsible for sending single byte
characters to LCDd (whatever encoding).

I am not agaist using UTF-8 as input. If we want to use it, my opinion
is not to apply it to some 'widget text value', but to the whole input
before it is parsed.</pre>
    </blockquote>
    I would really appreciate UTF-8 as input character set.<br>
    My current solution is to run the entire computer at ISO 8859-1, but
    that causes issues with samba.
    <br>
    <br>
    And yes, we should convert the whole input to a character set which
    is compatible with the display.<br>
    It doesn't make sense to apply the recoding only on parts of the
    input.<br>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">

By using libiconv we may get rid of mapping non ISO 8859-1 encoded input
to CGROM values. Or not.</pre>
    </blockquote>
    Yes I think so.<br>
    It's my understanding that, one put UTF-8 encoded data in and get
    ISO 8859-1 encoded data out. (Or whatever encodings one want.)<br>
    <br>
    But so far I only used the standalone program not the lib.<br>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">

However, auto-detecting the system locale only works if client and
server run on the same system and share the same locale (which might not
be true for LCDd started at boot time and a client that runs in a user
session).</pre>
    </blockquote>
    The display side is the easy one. Either the character set of the
    display is known or we use ISO 8859-1 until someone has a better
    matching suggestion.<br>
    <br>
    On the client side one could use the locale of the server or a
    default character set (UTF-8 for example).<br>
    In my opinion every client should be able to set its character set
    individually. Because every client of a server could run in a
    different locale. <br>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">

Library dependencies and compatibility are another topic for some future
discussion.</pre>
    </blockquote>
    afaik iconv() is part of the GNU libc.<code></code>I don't see any
    mayor Problem there.<br>
    <br>
    Regards<br>
    Stefan<code><br>
    </code>
    <blockquote cite="mid:[email protected]" type="cite">
      <pre wrap="">

Regards,
Markus


On 27.02.2014 21:47, Martin Tharby Jones wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hello,

I've attached a patch which provides a first step towards
internationalisation of LCDproc.

I'm a British English speaker with minimal second language skills so I
apologise that I have only addressed those areas that are relevant to
me. My problem was that I have a number of Celtic &amp;  Gaelic tracks in
my music collection and the accented characters used in those
languages were not being displayed correctly.

UTF-8 characters greater than 0x7F were displayed as two or more
strange characters:


With the patch and a display that supports ISO-8859-1 most western
European languages can be displayed:



I've also added string support for Unicode on graphic displays:


I've not done title or scroller widgets because I feel graphic
displays should support pixel level scrolling and proportional spaced
fonts which would require more work than I am prepared for (I don't
have a graphic display). Basic string support was coded as proof of
concept and as a test case.

There is obviously more to do but the code in the patch meets my
requirements and I hope will be of use to others.

Further work I have thought of:

  * Conversion of menu text
  * Use of gettext() and conversion for system screens
  * Use of gettext() and conversion for lcdproc screens

Regards

Martin
</pre>
      </blockquote>
      <pre wrap="">

_______________________________________________
LCDproc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="http://lists.omnipotent.net/mailman/listinfo/lcdproc">http://lists.omnipotent.net/mailman/listinfo/lcdproc</a>

</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------060201030202080901070309--

--===============0224458797300104742==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc

--===============0224458797300104742==--