Re: Why dose art not use fontconfig?

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/

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Why dose art not use fontconfig?

Thread: Re: Why dose art not use fontconfig?