Re: Fonts in XFree86 4.1.0
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
Reply to: