[Pkg-fonts-devel] Draining the font swamp

Angus Lees gus at debian.org
Tue May 22 23:36:53 UTC 2007

On 5/21/07, Nicolas Spalinger <nicolas at spalinger.org> wrote:
> > 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

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.

- Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20070523/61909327/attachment.htm 

More information about the Pkg-fonts-devel mailing list