[Pkg-fonts-devel] Draining the font swamp
nicolas at spalinger.org
Mon May 21 00:13:56 UTC 2007
> There has been some confusion and dissatisfaction over the treatment of
> fonts in Ubuntu for a some time now, and no common understanding of how to
> improve the situation. I spent a little time thinking about this today, and
> would like to present some questions whose answers I hope will help us to
> make some progress.
> Please correct me where I've misunderstood, as I've only done some cursory
> research here.
Hi Matt and everyone,
Thanks for raising these key issues. Here are some initial thoughts and
pointers from my perspective.
> We seem to have:
> - Loads of fonts, in various formats (TrueType, Type-1/PostScript, PCF
> bitmap, Metafont, others?) supporting various character sets, of varying
> - fontconfig, a font management framework which seems to be used by of the
> applications we care about in one way or another. It catalogues the fonts
> on the system and is independent of any window system, font rasterizer,
> etc. It just knows about fonts and provides an API to find a font based
> on complicated matching criteria.
> - DeFoMa, which attempts to allow packages to register fonts with whatever
> font management frameworks might exist.
> - TeX. Enough said.
It's worth pointing out that with the new texlive2007 in Debian
unstable, it's also possible to access TrueType/OpenType fonts from TeX
(including smart fonts) via extensions like Xetex:
(hats off to the Debian Tex task force!)
> - freetype, a font rasterization engine which also has some font management
> capabilities, also used by most applications we care about. Knows how to
> take fonts and strings and create bitmaps.
> - Xfont, which provides font services (including selection and rendering)
> through the X server. This is basically obsolete in favour of client-side
> - Xft, a font API for X applications which uses freetype and supports
> Xrender or plain X drawing to put text on a display.
> I don't know:
> - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications
> using those APIs ask for a font specification
> - Which applications ask for which font specifications, and where that's
> configured (sometimes in the application itself, as in Firefox)
There's unification happening via the TextLayout summits bringing
together the key font experts in the community:
Some blog entries on these meetings:
The next one will be hosted by Akademy 2007 and there will be a report
during GUADEC 2007:
> - Which fonts are any good, and for which languages (no easy answer here)
Yes, we need an ongoing review and it's no easy task.
Some initial work has been started here:
And there are various ITPs underway for these fonts.
I really think the current selection of fonts in a default install needs
some serious fixing. Certain packages need to be split, renamed, others
need to be moved back to universe as they are more decorative. The way
they tie in with langpacks probably also needs review.
> - Which criteria are important for selecting which font to use in which
> context (language, character set, ...)
I'd say license freeness, unicode coverage, glyph quality, availability
of smarts. We probably need a large-scale poll among translators,
LocoTeams and users. Although at this stage - but I hope everything is
getting in place for a change - for some locales a less than beautiful
and feature-rich font is always better than nothing.
This is why engaging (funding?) more artists and script experts to
design fonts for Debian/Ubuntu is important. The more fonts are
available the better the various font-related elements in the free
desktop stack can get tested.
At the LGM (Libre Graphics Meeting in Montréal) at the beginning of the
month there was discussion about setting up a common font QA website
between projects like scribus, OOo, OFLB, fontconfig and fontforge. A
central place to report troubles with fonts.
> - Whether fontconfig requires adjustments in order to respect those criteria
One key aspect is having a saner font menu by default along with the
ability to do more granular font management based on the font metadata.
Some of the thinking on this is available on
This fontconfig bug on glyph blacklisting is probably relevant to the
Also the fontconfig snippets should go upstream to reduce the deltas
with other distributions.
> - Whether we still need all these horrible bitmap fonts
You mean the fonts available in the x-fonts* packages?
I would suggest a poll on usage and possible demotion to universe or
specific langpacks. Might be different for CJK fonts.
> - Whether we still need server-side fonts for anything
At the LGM we organized a font BoF and Keith Packard (X.org and
fontconfig) said that an elegant solution might be to redirect the
server-side calls to fontconfig until the few remaning apps are fixed.
> - Whether we need DeFoMa
Yes, I'm also wondering what role DeFoMa should play.
Given the trend to unify the layout rendering engine across the free
desktop, the growing availability of quality truetype/opentype fonts
under a good license, and the growing quality of the free toolset to do
font design (inkscape, fontforge, fonts:ttf), do we still need DeFoMa's
approach? Is DeFoMa really maintained?
More information about the Pkg-fonts-devel