Re: fontconfig and Ghostscript

Around 17 o'clock on Apr 19, Raph Levien wrote:

>    Right now, I'm basically trying to figure out what's involved. I
> have Keith's Guadec paper, and I saw some mail on the mailing list.
> The Guadec paper is a little too vague and high-level for me. I was
> not able to find the fontconfig manual, even though the paper promises
> that it's available.

The fontconfig manual is in the XFree86 CVS repository, at

	xc/lib/fontconfig/src/fontconfig.man

I'm planning on making a separate fontconfig release after I've ironed 
out a few remaining semantic issues with font directories.  I'd also 
prefer to wait until after testing with Ghostscript in case that requires 
significant changes to the library.

> 1. Is it better for Ghostscript to link to the fontconfig library, or
>    to parse the fontconfig files itself?

You can do either, but for font accessors, I'd prefer you to give the 
library a try.  I'm more than willing to modify the library as needed so 
that it works for you.

> 2. I'm confused about whether fontconfig actually needs to open all
>    the accessible fonts using FreeType. If so, there's a performance
>    problem.

Fontconfig needs to gather information about the set of available fonts.  
The original Xft implementation did this by opening all of the fonts every 
time an application started.  That's really way too slow, especially now 
that fontconfig scans the entire font looking for blank glyphs and mapping 
it's charset.  So, fontconfig caches the data on disk.  It uses two 
caches, per-directory caches which are built with the 'fc-cache' program 
and per-user caches which are automatically maintained by the library.

I plan on fixing fontconfig to use the directory and directory cache-file
mod-times to validate the cache contents; this will avoid problems when 
the cache file is out of date.

> 3. It's pretty clear that fontconfig provides most of the functionality
>    of Ghostscript's Fontmap. However, we're extending this functionality
>    considerably. Is fontconfig powerful enough?

If it isn't, it can become so.

> There is also work in the HEAD branch that is designed to support
> substitution - particularly the use of TrueType fonts in contexts
> where the document calls for a Type1. I don't have a good reference
> for this. Igor Melichev is our primary developer. For those who are
> interested, querying on the gs-devel mailing list is probably the
> best idea.

Fontconfig has some substitution capabilities that are driven by the 
configuration file; we should see if those are sufficient for your needs.

> Also, I'd like to add my voice against XML for the fontconfig file
> format. I used XML in gnome-font, and feel it didn't help in any
> significant way. We are reluctant to add an XML parser to the library
> dependencies for Ghostscript. A simple text format would be preferred.

A simple text format was tried in Xft and a disaster ensued.  The basic 
problem is that I have one consumer (fontconfig) and many producers (KDE, 
Gnome, Mozilla) for the font configuration data.  I need a way that those 
GUI-based tools can modify the system font configuration without requiring 
that they contain a complete (and up-to-date) parser for a custom language.

KDE ended up stealing the parser bits of Xft and integrating that into 
their font configuration tool.  This makes it impossible to extend the 
syntax of the system in any substative way.  It also made the 
configuration somewhat brittle -- their configuration tool could handle 
some of the file content but not all.

Using XML provides a simple extensible syntax that is easily parsed by the
library (using expat) and easily edited by GUI tools in a non-destructive
way (using libxml).

XFree86 includes versions of both libraries now, and if you use the 
fontconfig library, the underlying use of XML would be hidden from your 
application.  I'm currently refactoring the XML support in fontconfig so 
that it can be built against either expat or libxml2, that will reduce the 
memory cost on systems already using libxml2 but not using expat.

> I'd like to harmonize with fontconfig, but I'm not yet convinced
> that it's a technically sound decision.

I'm more than willing to work with Ghostscript to make it possible to 
share configuration; we've got a horrible mess out there today and I'm 
more interested in fixing the problem than in selling my current snakeoil.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab