>On Tue, Jul 27, 2004 at 09:55:39AM +0100, Alastair McKinstry wrote: >> >> I think some of the stuff in console-cyrillic should be merged >> into console-common post-sarge; console-common is due for a >> rewrite: mostly to debconf' the font, etc. settings, >> but also make it more robust.
>I see that many of the fonts in console-data (not only the Cyrillic) >have multiple variants for different encodings. Is this intentional or >due to the history of the package? All fonts in console-cyrillic have >different faces and use some custom artificial encogings. The real >encoding is chosen by ACM. The collection of fonts and keymaps in console-data is mostly historical rather than planned. >> Conversely, some of the cyrillic fonts/keymaps in >> console-data may be better off in console-data; > >It is possible to optimize the fonts and keymaps in console-data. The >problem is that all maintainers of this package added stuff to it but >only on request and after negotiations. As a result some of the files >in console-data are rarely used and some languages and keyboards are not >supported at all >I think we should not base the debconf questions on the existing data >but develop them in some generic way. Then the files that are necessary >to support the configurations handled via debconf should be in >console-data. All other files are obviously rarely used and should be >moved in other packages. > >> the idea should be console-common as standard, with >> console-tools | kbd choice, and console-data | console-cyrillic. > >At present console-cyrillic is an alternative of console-data. In >sarge+1 I'd like to see this package not as an alternative but as a >complement - all important stuff is in console-data and console-cyrillic >is one of the packages containing the less used data. > >Another variant is this: two packages console-data-base and >console-data. The first contains the important data and the second more >rarely used files. In this way console-cyrillic can be obsoleted. I favour minimising the amount of console data in base, but console-data should always be present: think of a blade system without console, but someone hotplugging a monitor and keyboard in; for most of its life we don't need all the data currently in console-data, but some of it we'd need in a hurry to debug issues. There is also the Unicode data in /usr/share/unidata; thats a 1.4 MiB chunk that we rarely need .. I think console data should be optimised into console-data, console-data-optional, console-cyrillic. >Ofcourse in both of these packages the data should be well organized. If >you want I can help with this. I am not happy with the current state of >console-data. Help appreciated, especially on the fonts end. I had not planned on much work for fonts for sarge+1; If I get console-common / keyboards sorted out in a 6 month release cycle, I'll be very happy. >> loadkeys should work with use X keymaps. > >This is great! Do you know who will work for this and how it will be >implemented? I'd volunteered for this. Apparently the X code is now modular enough that I can dynamically link in code to parse the X keymaps. I intend to do this: - separate out the keymap parsing code from loadkeys / kbd-chooser. Move it into libconsole. One code base. - Create a wrapper to load the X keymap parsing code in the same way, so loadkeys can load X keymaps. - "Merge" the console-data and X keymaps, so that we only need one set eventually. With loadkeys / dumpkeys we can dump the keymap (to /etc/console/boottime.kmap.gz) so that we don't need X keymaps or X to boot.. but we only need one keymap selection (X's) and to set the keymap once (possibly speeding up booting into X). >Anton Zinoviev > Regards Alastair -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
