I had lunch with, then spent the afternoon with Brian Stell of
Mozilla. He is on a mission to make Mozilla printing work
Linux, especially the i18n bits. Already, he's provided us
and test cases for incremental Type 11 fonts.
There are a lot of tricky issues, and the GNU/Linux
historically done a poor job dealing with printing. It's an
cooperation between many diverse pieces is needed, but
that's really motivating a solution except people's
is trying to solve the problem the Right Way for Mozilla,
hope that others might follow.
Among other things, Brian is trying to figure out which
PostScript and PDF to target. For compatibility with existing
printers, you want to generate lowest common denominator
But there are also advantages to generating more recent
example, you can drop alpha-transparent PNG's into a PDF 1.4
they'll render correctly. That's not possible with any
PostScript, or with earlier versions of PDF. On the font
(most?) existing printers can't handle incremental Type 11
though they're in PostScript LanguageLevel 3 and also many Adobe
interpreters before that (2015 and later).
A good solution would be to generate the latest stuff, and have
converters that downshift it so it works with older
printers. Alas, no
good solution exists now. Ghostscript can rasterize without
but sending huge bitmap rasters to PostScript printers is
generally not a good idea. pdftops can preserve the higher level
structure (fonts, Beziers, etc.), but is limited in many
among other reasons because it doesn't contain an imaging
at least for the time being, it seems like the best
compromise is to
have a codebase that generates various levels of PostScript
A chronic problem in for GNU/Linux is a mechanism for users
fonts, and applications to find them. At least five major
platforms need fonts: Gnome, KDE, Mozilla, OpenOffice, and
also have a number of important traditional (I don't really
say "legacy") applications that use fonts: TeX, troff, and
among them. Plenty of other applications need fonts,
the vector graphics editors, Gimp, and so on. I suppose I should
mention X font servers too.
Most applications that need fonts have a "fontmap" file of
This file is essentially an associative array from font name to
pathname in the local file system where the font can be found.
Actually, you want a lot more information than just that,
encoding, glyph coverage, and enough metadata at least to
fonts into families. In some cases, you'll want language
particular for CJK. Unicode has a unified CJK area, so a
Simplified Chinese and a Traditional Chinese font can all
same code point, but actually represent different glyphs. If
browsing a Web page that has correct language tagging,
want the right font to show up. Unfortunately, people don't
do language tagging. In fact, this is one area where you get
more useful information out of non-Unicode charsets
the Unicode way (a big part of the reason why CJK people
I think). If the document (or font) is in Shift-JIS
it's a very good bet that it's Japanese and not Chinese.
This is why, for example, the gs-cjk team created a new
fontmap format (CIDFnmap)
for Ghostscript. In addition to the info in the classic
Fontmap, the CIDFnmap contains a TTC font index (for .ttc
which contain multiple fonts), and a mapping from the
encoding to CID's, for example /Adobe-CNS1 or /Adobe-GB1 for
Simplified and Traditional Chinese, respectively.
To make matters even more complicated, as of 7.20, we have
fontmap format, the xlatmap. The goals are similar to the
but with different engineering tradeoffs. One of my tasks is
out what to do to unify these two branches.
In any case, there are really three places where you
access fonts, and hence fontmaps. First, the app needs to be
choose a font and format text in that font. That latter task
font metrics information, including kerning and ligature
for Latin fonts, and potentially very sophisticated rules for
combining characters in complex scripts. These rules are
embedded in the font, particularly OpenType
formats, but more often not for older formats such as the Type1
family. Interestingly, you don't need the glyphs for the
The second place where you need the font is to display it on the
screen. Historically, these fonts have lived on the X
server. But the
new way is for the client to manage the font. The XRender
supports this approach well, as it supports server-side
glyphs supplied by the client. Even without XRender, it
makes sense to
do the glyph rendering and compositing client-side, and just
to the X server as an image. Maybe 15 years ago, the performance
tradeoff would not have been acceptable, but fortunately CPU
increased a bit since then.
The Xft library is one possible way to do font rendering,
but I'm not
very impressed so far. Among other things, it doesn't do
positioning, so rendering quality will resemble Windows 95
The third place where you need the font is when you're
document. In most cases today, it's a good tradeoff for the
embed the font in the file you're sending to the printer.
you don't have to worry about whether the printer has the
font, or has
a different, non-matching version. If you do that, then
doesn't actually need to rely on fontmaps at all; it just
fonts from the file. However, a lot of people don't embed
fonts, so in
that case, Ghostscript has to fudge.
So how do you install a font into all these fontmaps?
a mess. There are various hackish scripts that try to update
multiple fontmaps, but nothing systematic.
One way out of the mess would be to have a standard fontmap
possibly API), and have all interested apps check that file.
an attempt to design such a file format, but so far I'm not
it. For one, it's not telling me all the information I need
substitution well (the main motivation in Ghostscript for
and xlatmap file formats). Another matter of taste is that
it's an XML
format file, so we'd need to link in an XML parser just to
what fonts are installed. I'd really prefer not to have to
I realize that the Right Thing is to provide enough feedback
so that he can upgrade the file format, and we can happily
use it in
Ghostscript. But right now, I don't feel up to it. The
complex and I barely feel I understand them myself. Also, I'm
concerned that even fixing fontconfig for Ghostscript still
solve the problems for other apps. After all, Ghostscript
really need the font metrics, just the glyphs. Even thoroughly
obsolete apps like troff need to get .afm files for Type1
less font metrics from TrueType fonts). GUI apps on
really caught up to the sophistication of mid-'80s desktop
apps on the Mac. As far as I can tell, fontconfig currently
good story for metrics or language info.
What would really impress me in a standard for fontmap
a working patch to get TeX to use the fonts. But perhaps
this is an
overly ambitious goal.
In any case, I really enjoyed meeting Brian in person today, and
commend him for having the courage to attack this huge problem
starting from the Mozilla corner.