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
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
