> 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
> quality
>
> - 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:
http://packages.debian.org/unstable/tex/texlive-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
> fonts.
>
> - 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
So gnome/kde have pretty much settled on using fontconfig+freetype+xft exclusively for their fonts (and rendering it client-side). There's very little new gui code now that doesn't use xft et al via some widget library dependency.
Note that fontconfig, freetype and xft are different libraries designed to work together - and listing them as separate font pieces like thats a problem is a bit inaccurate.
> - 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:
http://www.freedesktop.org/wiki/TextLayout
http://live.gnome.org/Boston2006/TextLayout
Some blog entries on these meetings:
http://labs.trolltech.com/blogs/2007/03/30/working-towards-a-unified-text-layout-engine-for-the-free-desktop-software-stack/
http://rants.scribus.net/2006/10/31/boston-text-layout-summit/
http://mces.blogspot.com/2007/04/metrics-hinting-and-kerning-do-mix.html
The next one will be hosted by Akademy 2007 and there will be a report
during GUADEC 2007:
http://www.guadec.org/node/659
> - 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:
http://www.freedesktop.org/wiki/Software/Fonts
http://wiki.debian.org/DebianInstaller/GUIFonts
http://unifont.org/fontguide/
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
https://wiki.ubuntu.com/FontManagement
This fontconfig bug on glyph blacklisting is probably relevant to the
language contexts:
https://bugs.freedesktop.org/show_bug.cgi?id=7528
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.
You're going to need this for a long time yet - unless you plan on dropping support for Xaw apps, X11 apps displayed remotely from other unices, etc.
> - 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?
So I'm the current 'maintainer' for defoma. It hasn't been developed for years (I wasn't the original developer), although I am still rolling in any patches people submit to bts, etc. So it *is* "maintained", but that isn't what you were asking..
I'd like to see everything new using fontconfig. Some things (like TeX) will require massively invasive changes before that ever happens (likewise, fontconfig will probably never deal with metafont, etc font formats), and /some/ path for integrating with the old world would be nice.. I took on defoma maintenance because it filled a hole that nothing else did - unfortunately the implementation is some quite horrific perl.