Re: Why dose art not use fontconfig?

[Jeff Teunissen]

Isaiah Beerbower wrote:
> Hello all,
> 
> Just a quick question about the art back end: For what reason dose it
> not use fontconfig?

Since I'm the guy who suggested using NeXT Font packages (which the Art
graphics target supports), as well as the idea of New Font (nfont) packages, I
suppose I should describe why it was done.

Alex Malmberg wanted a font system that:

   1. Gives -gui all the information it requires.
   2. Gives -gui all the information it _wants_ to have, but doesn't need.
   3. Does not require a library-managed font cache.
   4. Is localization-capable.
   5. Allows complete font families to be distributed together, or separately.
   6. Can contain both scalable and bitmapped ("screen") fonts.

The information contained in NeXT-style .font packages (which can be retrieved
from any of the remaining software archives out there, by the way) includes
all the information necessary for the Application Kit's font system to do its
job, at least for Adobe Type 1 fonts.

The single most important piece of information to the AppKit is the font's
PostScript name, which is a string of characters unique to that specific font
face, and COMPLETELY unrelated to the font's "display name" (the name by which
a user refers to it).

Because it's so important to know, this is the piece of font information the
AppKit uses as a "key" by which to enumerate and unique its font list. Since
it's precisely unique to each font, and not dependent on the font's format
(it's the same for Type 1, TrueType, and OpenType), using the PS name is
literally the *only* reliable way to identify a font. That's why it's found in
RTF files (including those written by Microsoft Word!) as well as PDF and
PostScript files -- it's something that You Need To Get Right(tm) in order to
have printing that works or to have files that work right between machines,
let alone platforms. That would be one reason why fontconfig is insufficient
for things like GhostScript, and anything else that really needs fonts to be
consistent...like GNUstep (which is broken by design when using X or
fontconfig, since this necessary piece of info can't be accessed without
parsing all the actual font files).

Point 2 is relevant to the Font Manager, and exposed to the user by the Font
Panel. When "Times Bold Italic" is selected in the font panel and you switch
to "Courier" in the left column, the font manager should choose a face that's
the most like the old selection that it can find ("Bold Oblique"); that's
where the weight and properties of a font come in. It becomes more useful when
you have font families that contain lots of faces, like Helvetica Neue Std (11
different faces of various weights, widths, and slants -- from Extralight
Condensed to Ultrablack Wide Oblique). This is something that's hard to get
right in a limited amount of time (can't let program startup take 5 minutes,
after all) and fit into the AppKit's APIs at the same time.

Another feature there is the render hints, which allow the font packager to
tell FreeType how the font looks best. Fontconfig gives you a crude version of
this by having users edit their config files to tell it at which _point sizes_
to render as bitmaps and which to render as outlines. But some fonts are
well-hinted and some want the auto-hinter, and some don't look good either way
and should be rendered without any hinting. This is _possible_ to achieve with
fontconfig, but it's a PAIN.

Point 3 is partially a reaction to something that drove people using -xlib
INSANE, because GNUstep used to crash peoples' X servers all the damn time
while building the font cache (this was not *technically* -back's fault -- the
typical X server knows about far more font files than it can have loaded at
any given time, and -back would basically tell the server to load every font
it knew about one at a time). Plus it was prone to requiring that the user
deleted his/her font cache regularly so that it could tell when fonts were
added or removed, and Alex wanted something that would, at most, require a
program to get restarted when you added or removed fonts.

Point 4 is easy to overlook; who cares that "Bold" in German is "Groß", or
that Japanese fonts ought to have Japanese names when in a "ja*" locale, and
Romanized names in say, French and English locales?

Point 5 is another one that's easy to overlook, especially because there's no
central database of free nfonts and FontInfo property lists available for
those fonts that could be downloaded or bought elsewhere and assembled by the
user. Well, we wanted to set one up but nobody ever had the time to do it. I
can't say much other than "my bad", it made the system less useful than it
should have been.

Point 6 is somewhat less important these days, but it does make display much
faster.

New Font packages are STILL the only system being used with GNUstep which meet
all six criteria (fontconfig meets one and a half), so I consider it a bit of
a coup that we could have come up with something so simple that worked so well.

Fontconfig COULD be used successfully if a secondary font cache were also
used, containing the information that GNUstep needs but that isn't provided by
fontconfig itself. Without that second font cache, it's just permanently
broken and only pretends to work.

-- 
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek at d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project     http://www.quakeforge.net/
| Specializing in Debian GNU/Linux           http://www.d2dc.net/~deek/