discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why dose art not use fontconfig?


From: Jeff Teunissen
Subject: Re: Why dose art not use fontconfig?
Date: Wed, 22 Aug 2007 16:09:30 -0400
User-agent: Icedove 1.5.0.10 (X11/20070307)

Isaiah Beerbower wrote:
> On 8/21/07, Jeff Teunissen <spamtrap@d2dc.net> wrote:

[snip]

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

This would be a pretty easy thing to do with the [n]font system -- we
considered doing it at the outset, but Alex preferred to keep it simple for
the first implementation. Since he was the one actually writing the code, he
won. :)

With the [n]font system, all you have to do when looking for new fonts (and
noticing that fonts have been removed) is scan the four font dirs for changes,
either on-demand or periodically, load the FontInfo.plist files (and note the
existence of FontName.font dirs) and move on. Scanning a directory for changes
is a fast process, so font handling with art is really quick.

With a database-driven font handling system like fontconfig or XLFD, this is
way more difficult but still not beyond the realm of implementation. However,
with lots of fonts in the system this takes a LONG time so will never be
"immediately". On my laptop containing about 800 distinct font files,
fontconfig takes about four seconds to rescan all of the font directories even
when it doesn't need to update the caches. If it did need to re-cache
everything, it would take on the order of a minute. If GNUstep dealt with a
secondary font cache those times would be at least doubled because each
TTF/etc. file would have to be examined twice instead of once.

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

Fontconfig localizes on a font-by-font basis. Some of Microsoft's fonts have
localized face names, so "Andale Mono Regular" can show up as "Andale Mono
Обычный" in Russian locales...but in the same locale, "Baskerville Cyrillic LT
Std Upright" doesn't change at all. A New Font package for Baskerville would
be able to localize the names, or have them use the fall-back localization
plist Alex created.

[snip]

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

It is a more complex approach, and one which makes it harder to do right. That
said, it isn't too difficult (though you still don't get what you want, as I
outlined above).

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

As I said, it's a nice, fast, simple system that should have been
better-supported but wasn't because I didn't want to have to do it. ;)

I'm perfectly happy to contribute to a New Font database, I just didn't want
to have to run the damn thing. I have quite a few hand-crafted nfonts that
could be distributed, and even more that couldn't be (because the fonts
themselves can't be -- about a third of the Adobe OpenType font library), but
which could easily be put into a database somewhere for people to download and
assemble with their own font collections -- perhaps using a program like Font
Manager. You open up "Font Manager", tell it "Package this group of TTFs", it
calls out to a site and grabs the FontInfo plist, and chunks the whole thing
into an nfont which it then drops into your Fonts library and tells all the
running programs to rescan the font dirs.

Backbone in CVS has a few free nfonts that use hand-crafted info plists (the
DejaVu font set, covering most stuff that's not CJK); you're welcome to use
them in anything else, under GPL.

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

Fontconfig is only useful for getting the basic font information; its main
purpose is to do the searching. To get the extra info *step needs requires
using FreeType on the font files.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]