I am very glad for the initiative to create the pkg-kbd project. So far I have informed only Alastair about my work for the console data, now we have a public mailing list so more people can be involved. Unfortunately I was more busy that I supposed to be and fortunately the work I wanted to do is already almost complete. :-)
Last year I promised Alastair to create a new, consistent collection of console fonts. This task is done. But when I looked more closely at the console-data package in order to see how to integrate the new collection I was scared - this simple in nature package turned out to be so complex! :-O Alastair had told me that he intends to create a system that allows the X keyboard definitions to be used on the console. This task is quiet difficult but necessary in order to simplify the console-data package. So I decided to try to create a quick and durty "X to console" translator that could also serve as proof of the concept and helped Alastair to implement easier his system. This task is also already done and tested for the "AT" keyboards. It works better than I had initially supposed it to work; it will allow us to configure the keyboard together for X and for the console. Due to lack of enough time I was unable to implement the Debian part of all this, i.e. to do any Debian packaging. I think it will be easier to create a completely new package that is not based on the current console-data. I have no idea about what should be its name. I have some uncertainty about how to package the keyboard part. I will give more info in another message. There is ready to commit code, probably we do not need another project on Alioth and I can commit in the SVN of pkg-kbd? On Mon, Sep 19, 2005 at 03:21:43AM +0300, Konstantinos Margaritis wrote: > On Κυριακή 18 Σεπτέμβριος 2005 22:43, Denis Barbier wrote: > > * kbd and console-tools have forked a long time ago, how to > > include fixes from both branches? I think from users point of view the only feature of console-tools that is missing from kbd is the support of fallbacks tables. For example if the console font does not have a gliph for say "a with diaeresis" some users will prefer to display "a" instead of "a with diaeresis" while others will prefer say question mark. With the kbd package the fallback table is always embedded in the font and only way to achieve this is to use two different fonts. I think that this feature is not vital so we can orphan console-tools. >From the developers point of view console-tools is superior to kbd because it has its own library. Alastair wanted to do the same for the kbd package and the upstream agreed. > * A universal way to setup console fonts and keymaps, regardless of > the actual locale. Sergey Udaltsov has discovered how to do the keyboard part, look at /etc/X11/xkb/rules/xfree86.xml and the keyboard configurator of GNOME. The font part is not tricky at all. > * Cyrillic locales. In my understanding these > are probably fit in the above subcategory, but I'll refrain from > doing that statement as I'm not familiar with the actual intricacies > of setting up the console for Cyrillic. If possible the > console-cyrillic code should be merged into the True. The package console-cyrillic was created because both kbd and console-tools did not have very involved maintainers. > Assuming that UTF-8 is used universally, this should make things > easier for us actually and spare us the effort of having to handle > different encodings. In my opinion, I don't think we should even > bother to support older encodings for the console. Just go UTF-8 all > the way. The kernel does not support fully UTF-8 on the console. So far many patches have been submitted and rejected by the kernel developers. :-) Acording to them the kernel should stay as simple as possible, the text mode Linux console should be used only in emergency cases (aka single user mode) and in most cases people should use programs such as jfbterm (even for the Latin1 languages). Currently the CapsLock key does not work properly in UTF-8 mode. The Compose key also does not work. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
