MH> 1) What can the X server and xfs each currently do WRT #1 above The scalable backends ``type1'', ``speedo'' and ``freetype'' can recode fonts to an arbitrary encoding using a common, extensible database of encodings. ``speedo'' and ``type1'' are limited to 256 codepoints, ``freetype'' knows no such limitation.
The scalable backend ``xtt'' can recode a font to any encoding in a built-in set. For more information, please read http://www.xfree86.org/current/fonts.html which can also be found in the source and binary trees under the name ``README.fonts''. MH> 2) What work needs to be done to xfs/Xserver to finish the job MH> (itemized preferably), and how complex would this work be to MH> get done? What amount of timeframe would it take? Some people believe that the bitmap backends should be able to do similar recoding. My personal opinion is that this recoding should be done at bdftopcf time. The Debian and RedHat packages should not contain the reencoded fonts; instead, they should only contain ISO 10646 fonts. The post-instal- lation script should determine the set of encodings that the system administrator wants installed (for example, by reading some global configuration file or simply by prompting the user), and build the needed reencoded files. Of course, the system administrator should be able to change her mind at a later time and regenerate the fonts. This approach is no different, I believe, from the one that Debian already use for generating locales. I don't know about RedHat. Currently, bdftopcf does not yet do such reencoding, so Markus has written a Perl script to do something similar at the BDF level. I will implement recoding in bdftopcf as soon as I've integrated the changes to fontenc that I've mentioned earlier. * * * Why not do the reencoding ``on the fly'' at PCF parsing time, as many people have suggested? A simple-minded approach would consist in reading the whole Unicode font into memory; this is clearly something we don't want to do, as it requires too much memory (although only transiently). As to recoding a PCF font on the fly (i.e. only read in the needed glyphs), as the scalable backends do, there is a problem. At the time when you're reading the glyph data, you do know whether you're dealing with an iso10646-1 font or not; on the other hand, you don't yet know whether it's a matrix-encoded one, or a linearly-encoded one. The solution of only reencoding linear fonts is not acceptable, as it will make it next to impossible to explain to the users which fonts can be reencoded, and thus put a huge support burden on everyone (especially the distributors, by the way). After some thought, I came to the conclusion that you really need two reencoders: one ``on-the-fly'' for linearly encoded fonts, and one ``post hoc'' for other fonts. As you open a font to be reencoded, you assume it's linearly encoded; if you then realise this is not the case, you print a warning to the log, and try again using the post-hoc reencoder. In addition, you'd need to modify bdftopcf to generate a warning whenever it's told to generate a matrix iso10646-1 font. Doing all of that is not really difficult, but it is a rather tedious job, and not one that I'm really keen on doing. If anyone wants to tackle it, you may be assured of my help, but please wait until the fontenc changes have been committed (sometime this month, in all probability). Regards, Juliusz
