Re: Why dose art not use fontconfig?

[Isaiah Beerbower]

On 8/21/07, Jeff Teunissen <spamtrap@d2dc.net> wrote:
> 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.

Sweetness!

> 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.

With Font Manager I would like to be able to install a font and have
other applications see it immediately.

> 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?

Doesn't fontconfig have localization?

> 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.

And what are the reasons against using our own cache (supposing there
are some)? It sounds like a better approach.

I can see how it wouldn't be desirable to have GNUstep use every font
found by fontconfig. Fontconfig and FreeType can provide us with all
the information we need. IMHO nfonts are a pain to *have* to use (as
an option it would be fine). I want to download a font and be able to
install it as is.

In short, I think if we had our own font searching, and used
fontconfig for getting information from fonts, we would have added
convenience without sacrificing anything (again IMHO) important.

-- 
View my website at www.ipaqah.com.

"Facts are stubborn things, but statistics are more pliable." -- Mark Twain