Re: [PATCH] hd44780-charmap.h imon.c Russian charmaps
Yura Scheglyuk <[email protected]>
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
Hi! On 30.03.2011 3:09, Markus Dolze wrote: >> I made the new version of two additional Russian charmaps - CP-1251 >> (Windows-1251) and ISO 8859-5 according principle of previous patch of >> koi8-r charmap. I removed pseudo-graphics symbols because it's rarely >> used and remapping symbols like HEART and so on. > originally I was not a friend of adding these additional mappings as > they will encourage more users to implement mappings from other > languages and I think LCDproc should not need to cope with different > input character sets on its own. The possible solution to avoid growth of translation tables in code is giving user option to load custom mapping from file. And those mapping files may be distributed in contrib section. > Instead one solution would be to map Anything->Unicode->HD44780, e.g. > using libiconv. Unfortunately nothing like Unicode->HD44780 exists to my > knowledge so we will end up using our own mapping tables again and using > wide characters in the server core will require extensive rework of it > and I don't even think of doing this. As I remember you said about the goal to next major stream in development of lcdproc is Unicode support. It may tends to complete refactoring of code. I understand that in current stage of lcdproc it may be impossible. The possible solution to implement Unicode in lcdproc is the Google Summer of code - involve students to making some part of coding. AFAIK Google close timeline to accept projects to GSoC'2011. May be in next year? > Therefore, if you agree on having those tables as a compile time option > (e.g. ./configure --with-extra-encodings) I am happy to commit them. OK, if you can commit this patches with compile time option it would be fine. The main goal is to include this mappings in lcdproc source tree. So maintainers of unix distributions get options to build extended versions of lcdproc. -- Best regards, Yura Scheglyuk.