Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why dose art not use fontconfig?

15 views
Skip to first unread message

Isaiah Beerbower

unread,
Aug 15, 2007, 1:37:04 PM8/15/07
to Discuss...@gnu.org
Hello all,

Just a quick question about the art back end: For what reason dose it
not use fontconfig?

Thanks,
Isaiah Beerbower

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

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


Isaiah Beerbower

unread,
Aug 15, 2007, 1:41:02 PM8/15/07
to Discuss...@gnu.org
And when I said "dose" it is only natural that I meant "does" (=

Fred Kiefer

unread,
Aug 16, 2007, 5:33:17 AM8/16/07
to Isaiah Beerbower, Discuss...@gnu.org
Isaiah Beerbower wrote:
> Hello all,
>
> Just a quick question about the art back end: For what reason dose it
> not use fontconfig?
>
> Thanks,
> Isaiah Beerbower
>

The real reason for that choice could only be given by Alexander
Malmberg, who implemented the art backend.
I may be able to offer you a few hints, but none of it may be the true
reason.
Using the nfont concept offers some benefits over fontconfig. It allows
us to assign a Postscript name to a font, which is then used for
printing. All the other GNUstep backends need to guess a name here. The
nfont file FontInfo.plist allows you also to change the name of the font
of the type face to something more readable and to specify information
missing or wrong in the actual font data. In addition this concept
allows you to limit the available fonts for GNustep.

Overall I think this is not worth it, this is why I use fontconfig for
the xlib and the cairo backend, still I can understand when people take
a different point of view. If there is a demand for it, I could add
fontconfig for art as well as a compile time option.

Fred


Isaiah Beerbower

unread,
Aug 17, 2007, 12:09:35 PM8/17/07
to GNUstep Discuss

I agree. While these arguments against using fontconfig are valid, the
mere annoyance of having to create a bundle for each font you want,
and not being able to keep all your fonts in one place, out weighs
them in my mind.

In short, I think it would be a good idea if the art back end could
use fontconfig.

Jesse Ross

unread,
Aug 17, 2007, 12:59:11 PM8/17/07
to Isaiah Beerbower, GNUstep Discuss

This begs the question -- why make more adjustments to the art
backend when Cairo has been blessed as the backend of choice for
future development?

From Greg's blog ( http://heronsperch.blogspot.com/2006/12/plans-for-
change.html ):

> 5) Focus and concentrate on one and only one set of display
> technologies per platform. We expend way too much time and energy
> on maintaining mulitple backends (xlib, art and etc) when we really
> don't have to. For Linux/BSD we have two functional backends and
> another on the away for cairo. What's the point of this? In my
> opinion we should complete the cairo backend and deprecate BOTH the
> xlib and art backends. xlib is hopelessly outdated and libart isn't
> really supported by anyone anymore.

My suggestion would be that you develop FontManager (which is why I
assume you're asking, Isaiah) on top fontconfig exclusively, and see
if there is a way to help get the Cairo backend to the point where
art/xlib really can be deprecated, per Greg's plans.

J.


Isaiah Beerbower

unread,
Aug 18, 2007, 6:05:40 AM8/18/07
to GNUstep Discuss

Yep.

> on top fontconfig exclusively, and see
> if there is a way to help get the Cairo backend to the point where
> art/xlib really can be deprecated, per Greg's plans.

I'm ashamed to say that I haven't taken a good look at cairo yet. I
also don't have it running on my system yet. I've been able to compile
and install cairo, but it crashes when I try using it, and I haven't
been all that proactive in figuring out why. I'll see if I can't get
that working over the weekend ...

I guess it's just me being lazy ... (=

Riccardo

unread,
Aug 20, 2007, 3:12:19 AM8/20/07
to Jesse Ross, Isaiah Beerbower, GNUstep Discuss
Hi,

On 2007-08-17 18:59:11 +0200 Jesse Ross <gnu...@jesseross.com> wrote:

>>
>> I agree. While these arguments against using fontconfig are valid,
>> the
>> mere annoyance of having to create a bundle for each font you want,
>> and not being able to keep all your fonts in one place, out weighs
>> them in my mind.
>>
>> In short, I think it would be a good idea if the art back end could
>> use fontconfig.

There is an additional reason: Those bundles are very openstepish.
While I never really figured out the font system on X11 and find
installation of fonts tedious, on mac you just drop them in to the
Font folder. Moreover oyu have a system font folder, but also one for
each user. Nfonts allow this logic and I like that. It is one of the
few things I like more in art compared to xlib!

> This begs the question -- why make more adjustments to the art
> backend when
> Cairo has been blessed as the backend of choice for future
> development?
>
> From Greg's blog (
> http://heronsperch.blogspot.com/2006/12/plans-for-
> change.html ):

Because art and xlib still have advantages and having them is an added
flexibility?

>> 5) Focus and concentrate on one and only one set of display
>> technologies
>> per platform. We expend way too much time and energy on maintaining
>> mulitple backends (xlib, art and etc) when we really don't have to.
>> For
>> Linux/BSD we have two functional backends and another on the away
>> for
>> cairo. What's the point of this? In my opinion we should complete
>> the
>> cairo backend and deprecate BOTH the xlib and art backends. xlib is
>> hopelessly outdated and libart isn't really supported by anyone
>> anymore.

xlib works very well and has several advantages and it can be made
pretty fast too as myStep demonstrates. Art has a difference philosphy
and except for some bugs, it has a very high quality display, but
clearly slower in some cases. Personally I don't share the idea of
using cairo as a tool to support different platforms (like windows).

Art has for example that pretty nice font mechanism. What I'd like
would be a tool that could creeate the nfonts packages in an automated
and perhaps a visual way, including the name assignment.

Riccardo


Isaiah Beerbower

unread,
Aug 20, 2007, 8:59:11 AM8/20/07
to GNUstep Discuss

Fontconfig can be told to look for fonts in your Library/Fonts folder.
To say that nfont bundles are what allow such behavior is total
nonsense. Your example of how Mac OS X handles fonts proves this
point, seeing as Mac OS X does not use nfonts.

I am working on a font manager (called FontManager) for Étoilé.
FontManager will let you preview an uninstalled font, and will install
it for you if you want. This is far easier than any dragging and
dropping into a fonts folder.

FontManager will also be able to create nfont bundles. But the vary
fact that you want this process to be automated shows that it's an
inconvenience.

Gregory John Casamento

unread,
Aug 20, 2007, 10:08:50 AM8/20/07
to Riccardo, Jesse Ross, Isaiah Beerbower, GNUstep Discuss
> Because art and xlib still have advantages and having them is an added
> flexibility?
Although art is an excellent backend, the library it's based on, libart, is currently unmaintained, and cairo is actively maintained and more Postscript like. Xlib renders poorly, but is fast on very slow systems.

Yes, both have their advantages. ;)

GJC

--
Gregory Casamento# GNUstep Chief Maintainer

Hi,

Riccardo


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

Gregory John Casamento

unread,
Aug 20, 2007, 11:45:27 AM8/20/07
to Gregory John Casamento, Riccardo, Jesse Ross, Isaiah Beerbower, GNUstep Discuss
Allow me to rephrase... xlib renders fonts poorly in some cases. Xlib renders graphics just fine.

GJC
--
Gregory Casamento

Vaisburd, Haim

unread,
Aug 20, 2007, 2:31:04 PM8/20/07
to Discuss GNUstep
Gregory John Casamento wrote:

> Although art is an excellent backend, the library it's based on,
> libart, is currently unmaintained, and cairo is actively maintained
> and more Postscript like. Xlib renders poorly, but is fast on very
slow systems.

> [...]

> Allow me to rephrase... xlib renders fonts poorly in some cases.
> Xlib renders graphics just fine.

Xlib backend does not support rotation. Last time I tried the
semi-transparent
masks in Xlib, Xlib gave different results than art and art looked much
better.
So I guess there are a few problems with Xlib graphics, too.

I do hope that cairo backend will solve most or all the problems we have
on Unix.

--Tima


Yen-Ju Chen

unread,
Aug 20, 2007, 6:00:23 PM8/20/07
to GNUstep Discuss
My opinions is that art backend works fine now.
The effort to make it use fontconfig is disproportional to what users
will benefit.
It may be more useful in improving cairo backend.
It is just my 2 cents. :)

Yen-Ju

On 8/20/07, Gregory John Casamento <greg_ca...@yahoo.com> wrote:
> Allow me to rephrase... xlib renders fonts poorly in some cases. Xlib renders graphics just fine.
>

> GJC
> --
> Gregory Casamento
>
>
> ----- Original Message ----
> From: Gregory John Casamento <greg_ca...@yahoo.com>
> To: Riccardo <mul...@ngi.it>; Jesse Ross <gnu...@jesseross.com>
> Cc: Isaiah Beerbower <pub...@ipaqah.com>; GNUstep Discuss <Discuss...@gnu.org>
> Sent: Monday, August 20, 2007 10:08:50 AM
> Subject: Re: Why dose art not use fontconfig?
>
>
> > Because art and xlib still have advantages and having them is an added
> > flexibility?

> Although art is an excellent backend, the library it's based on, libart, is currently unmaintained, and cairo is actively maintained and more Postscript like. Xlib renders poorly, but is fast on very slow systems.
>

Jeff Teunissen

unread,
Aug 21, 2007, 7:07:52 PM8/21/07
to
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/

Isaiah Beerbower

unread,
Aug 22, 2007, 9:06:32 AM8/22/07
to GNUstep Discuss
On 8/21/07, Jeff Teunissen <spam...@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!

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.

Jeff Teunissen

unread,
Aug 22, 2007, 4:09:30 PM8/22/07
to
Isaiah Beerbower wrote:
> On 8/21/07, Jeff Teunissen <spam...@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.

Fred Kiefer

unread,
Aug 22, 2007, 7:26:24 PM8/22/07
to discuss...@gnu.org
I don't want to step into this discussion, I see the benefits of both
concepts and in the good old GNustep way I would suggest to have them
both in parallel and let the users choose what they prefer.
Today I extracted the font enumerator out of the art font files. If
anybody wants to replace it, now there is a clean and (more or less)
documented interface to do so. All you have to do is fill up FTFaceInfo
objects. The hard part here would probably be to get the font file paths.
I wont have the time to do this myself and I am quite satisfied with the
nfont concept.

Fred


Isaiah Beerbower

unread,
Aug 22, 2007, 9:08:53 PM8/22/07
to GNUstep Discuss
On 8/22/07, Jeff Teunissen <spam...@d2dc.net> wrote:
> Isaiah Beerbower wrote:
> > On 8/21/07, Jeff Teunissen <spam...@d2dc.net> wrote:
>
> ...

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

The fact that you would have to go to a special font database is part
of the annoyance. I want users to download fonts from the authors site
and just install them.

HOWEVER

For Font Manager, I had plans of using fontconfig and FreeType to
generate nfonts without any user, or other, input (other than, of
course, the font files).

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

Étoilé also has a default fonts package which contains the DejaVu
fonts plus many others.

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

unread,
Aug 23, 2007, 1:39:40 AM8/23/07
to

What author's site? There are only a handful of decent, free fonts available
and they all need tweaks to rendering to look decent.

> HOWEVER
>
> For Font Manager, I had plans of using fontconfig and FreeType to
> generate nfonts without any user, or other, input (other than, of
> course, the font files).

That is...ahh, "wrong-headed"; good nfonts can't be automatically generated.
The "mknfonts" tool was written to spit out a first-run stab at a skeleton
FontInfo.plist file, NOT as something you run on your fonts before installing
them! No automatic tool can do the job right except in the MOST trivial cases,
no matter how much fuzziness you put into it.

We're possibly dealing in two very different worlds here; I'm concerned with
typography here, while you're apparently dealing with a far less demanding
requirement -- "getting stuff into the font panel". The art back-end graphics
target was designed to do everything as perfectly as it could be done, to set
the bar for reference implementations (including font handling).

To compare the result of a tool (any tool) that spits out nfonts with what a
human does, let's take a look at DejaVu:

Given the DejaVu font collection (21 font files), mknfonts (which reads
TrueType info from TTFs and OTFs) would spit out five nfont packages, while
Backbone's has three -- System (DejaVu Sans, DejaVu Sans Condensed), System
Serif (DejaVu Serif, DejaVu Serif Condensed), and System Monospace (DejaVu
Sans Mono).

Why the difference, and why does it matter? Because the TrueType info for the
condensed faces of the three families describes them as being different
families, any automatic system will place them into new categories, using up
two extra slots in the font panel. It matters because reducing the number of
selections in the left side of the font panel makes selecting them faster and
easier for the user, and an automatic system can't tell that the letters
"Condensed", "Cond", "Cnd" always refer to the font face itself and not to the
family -- because they don't, they're just strings. It requires a human being
to do these things.

With only a few fonts on a machine this is not a serious problem, but people
who work with lots of text and need access to lots of fonts (say, in page
layout) will tell you that reducing clutter in their work is a Good Thing(tm);
it can mean the difference between having 80 items to wade through and 600.

For a more extreme example, take Helvetica Neue LT, which contains 52 font
files and shows up as 21 families in fontconfig. In nfont format it takes up
one slot and all of the faces are arranged sanely by weight, width,
outline/normal, and slant. On the disk, the nfont package is 1.6MB with an 11K
font info plist. How many names fit in a standard-sized font panel without
scrolling? You don't want to have to page-down three times to get through a
single font in the family list, do you? :)

Any font that has many uses is the same way, with many faces for different
purposes and desired results. Typography is more than just "Regular, Bold,
Italic, Bold Italic" and it deserves a good system to handle its complexity.
The OpenStep (and by extension, Cocoa) text network is rich enough to handle
the complexity of professional typography, it just needs to be exercised.

Fontconfig is a fine tool for what it is, really it is. It's just not capable
of dealing with anything beyond the basics. To make life easier for real
people, you have to do more. :)

Jesse Ross

unread,
Aug 23, 2007, 2:37:33 AM8/23/07
to de...@d2dc.net, discuss...@gnu.org
On Aug 23, 2007, at 12:39 AM, Jeff Teunissen wrote:

> Any font that has many uses is the same way, with many faces for
> different
> purposes and desired results. Typography is more than just
> "Regular, Bold,
> Italic, Bold Italic" and it deserves a good system to handle its
> complexity.
> The OpenStep (and by extension, Cocoa) text network is rich enough
> to handle
> the complexity of professional typography, it just needs to be
> exercised.
>
> Fontconfig is a fine tool for what it is, really it is. It's just
> not capable
> of dealing with anything beyond the basics. To make life easier for
> real
> people, you have to do more. :)

I was the person who suggested that Isaiah create Font Manager, and I
also suggested he build it on top of fontconfig exclusively. This was
under the assumption that to use any font with the art backend was to
have to convert it into a "strange", "non-standard" format, unused by
the rest of the world, thus resigning us to an environment of only
Helvetica and whatever else happened to be already converted to nfont.

After having read Jeff's history of nfont and the impetus behind it,
and actually taking the time to learn how nfonts work, I realize that
I was letting my ignorance get the better of me. Nfonts seem like a
smart idea and I am going back on my suggestion of all-out abandoning
them for fontconfig.


However, for the casual user unconcerned with typography (and even
for those who are, see below), I don't see an issue with Isaiah's
suggestion that Font Manager generate an nfont file. The important
point here is to see that as the first step. Casual users could stop
there, and use the font as it is. The conversion to an nfont package
should be as invisible as possible for those concerned only with
having a certain font available. For those who want a better
typographic experience, that generated nfont package doesn't have to
be the end. I'm imagining something like iTunes and it's ID3-editing
interface as the front end to the nfont plist.

Imagine you do install DejaVu via Font Manager, and end up with the 5
nfont packages that occur as a result of mknfonts. Shouldn't it be
possible to drag the Font Manager entry for DejaVu Serif Condensed on
top of DejaVu Serif and have those be automatically joined into a
single nfont (and thus a single entry in the font selection list)?
Clicking on the new DejaVu Serif listing should allow the user to
select a menu option named something like "Edit Font Settings", where
they are given a nice UI for modifying any of the given options for
an nfont, such as the RenderHints or Localized name.

Maybe I'm missing some technical reason why this is bad or not
feasible, but it seems like a good way give everyone what they want:
your typographic experience is directly proportionate to how much
time you put in tweaking and modifying your font settings (or
searching out fonts that are already pre-packaged as hand-crafted
nfonts). Lazy or apathetic users can grab any font they want, knowing
they will work; typophiles can tweak plist settings in a way that is
more integrated with Font Manager in order to have fonts rendered and
listed exactly as they want.

J.


Isaiah Beerbower

unread,
Aug 23, 2007, 7:18:39 AM8/23/07
to GNUstep Discuss
I'm not going to waist my breath arguing over what my app may, or may
not, be capable of doing. Since the feature in question hasn't been
implemented yet, you can hardly argue either way.

(:

I get smiles and giggles out of somebody who will compose a mail as
long as that to tell me something I haven't created yet doesn't work.

Well, thank you anyway for your "helpful" information,

Isaiah Beerbower

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

> > ...


> >
> > For Font Manager, I had plans of using fontconfig and FreeType to
> > generate nfonts without any user, or other, input (other than, of
> > course, the font files).
>
> That is...ahh, "wrong-headed"; good nfonts can't be automatically generated.
> The "mknfonts" tool was written to spit out a first-run stab at a skeleton
> FontInfo.plist file, NOT as something you run on your fonts before installing
> them! No automatic tool can do the job right except in the MOST trivial cases,
> no matter how much fuzziness you put into it.
>

> ...

Isaiah Beerbower

unread,
Aug 23, 2007, 7:28:59 AM8/23/07
to GNUstep Discuss
I also now see the reasoning behind nfonts. I didn't start this thread
just so I could shoot them down. I wanted to know what the original
reasons were ... and now I do.

Thanks,
Isaiah Beerbower

On 8/23/07, Jesse Ross <gnu...@jesseross.com> wrote:
> On Aug 23, 2007, at 12:39 AM, Jeff Teunissen wrote:
>

> > Any font that has many uses is the same way, with many faces for
> > different
> > purposes and desired results. Typography is more than just
> > "Regular, Bold,
> > Italic, Bold Italic" and it deserves a good system to handle its
> > complexity.
> > The OpenStep (and by extension, Cocoa) text network is rich enough
> > to handle
> > the complexity of professional typography, it just needs to be
> > exercised.
> >
> > Fontconfig is a fine tool for what it is, really it is. It's just
> > not capable
> > of dealing with anything beyond the basics. To make life easier for
> > real
> > people, you have to do more. :)
>

> ...


>
> After having read Jeff's history of nfont and the impetus behind it,
> and actually taking the time to learn how nfonts work, I realize that
> I was letting my ignorance get the better of me. Nfonts seem like a
> smart idea and I am going back on my suggestion of all-out abandoning
> them for fontconfig.
>

> ...

Jeff Teunissen

unread,
Aug 23, 2007, 1:29:14 PM8/23/07
to
Isaiah Beerbower wrote:
> I'm not going to waist my breath arguing over what my app may, or may
> not, be capable of doing. Since the feature in question hasn't been
> implemented yet, you can hardly argue either way.
>
> (:

Well, you *did* describe the feature as being, effectively, a glorified
mknfonts -- which is useful, but not sufficient. I would suggest something
more interactive, so the human using the program gets a chance to affect the
result.

:)

By the way, there was a (commercial) font manager for NeXTStep called
FontMonger IIRC that would take Adobe Type 1 fonts for the Mac and Windows,
build groups of .font packages (a .font contains only one face, so you need
them in groups to get a full font family), and generate screen fonts to reside
inside them. It was rather nice. IIRC, at some point it did some (rather poor)
conversions from TrueType to Type 1 (it had to be poor since TrueType fonts
contain quadratic Bézier splines, while PostScript/PDF/etc. use cubic).

[snip]

Jesse Ross

unread,
Aug 23, 2007, 2:14:44 PM8/23/07
to GNUstep Discuss
> Well, you *did* describe the feature as being, effectively, a
> glorified
> mknfonts -- which is useful, but not sufficient. I would suggest
> something
> more interactive, so the human using the program gets a chance to
> affect the
> result.

I would argue the reverse -- make the initial font conversion a
virtually invisible process initially, something that doesn't require
any additional user interaction, as painless as just dragging a font
into the Font Manager window or clicking the + button on the bottom
of the window and selecting the font.

Then, after the font is on the system and has gone through the
conversion/wrapping process, allow the user to make adjustments to
the nfont plist via a nice GUI frontend, if and only if they desire
that level of control.


J.

Jeff Teunissen

unread,
Aug 24, 2007, 5:53:26 AM8/24/07
to
Jesse Ross wrote:
>> Well, you *did* describe the feature as being, effectively, a glorified
>> mknfonts -- which is useful, but not sufficient. I would suggest something
>> more interactive, so the human using the program gets a chance to affect
>> the result.
>
> I would argue the reverse -- make the initial font conversion a
> virtually invisible process initially, something that doesn't require
> any additional user interaction, as painless as just dragging a font
> into the Font Manager window or clicking the + button on the bottom
> of the window and selecting the font.

As I mentioned, it's not just what's in the plist but what's in the package.
An automatic process cannot collect a font family correctly, so it's something
that needs a human being able to make decisions.

After all, isn't that what a computer is FOR? It does the grunt work, you make
the decisions. :)

Jesse Ross

unread,
Aug 24, 2007, 7:39:26 AM8/24/07
to GNUstep Discuss
>> I would argue the reverse -- make the initial font conversion a
>> virtually invisible process initially, something that doesn't require
>> any additional user interaction, as painless as just dragging a font
>> into the Font Manager window or clicking the + button on the bottom
>> of the window and selecting the font.
>
> As I mentioned, it's not just what's in the plist but what's in the
> package.
> An automatic process cannot collect a font family correctly, so
> it's something
> that needs a human being able to make decisions.
>
> After all, isn't that what a computer is FOR? It does the grunt
> work, you make
> the decisions. :)

Yep -- totally agree. But for quick and dirty, single font installs
(the kind that the great percentage of people who are not designers/
typographers would be doing), wrapping up that single font into an
nfont without asking any questions is probably the right route to go.

I see three easy solutions for how to generate a multi-font family
using Font Manager:

1) If the user drags in multiple fonts, ask the user if they would
like to package them as a single font entry, and have them provide a
name for the family

2) If fonts are already in Font Manager and the user wants to make
them a single font family, they can:

a) drag one font onto another font to automatically create a family
b) select multiple fonts and select a menu item named something
like Edit > Create Family from Selected Fonts

In all three cases, Font Manager should be smart enough to see where
the names overlap and use that as the family name (ie: if I have
"Helvetica Extra Black", "Helvetica Ultra Light" and "Helvetica
Thin", name the family "Helvetica"). If there is no name overlap, ask
for a name. That name should be easily edited from within Font
Manager, from both right in the main font list panel and in a
separate "font editing" UI (allowing me to do something like change
the name to "Helvetica Neue" from "Helvetica", should I choose).


Just to be clear, I agree that having good typography, and good tools
for designers is important. I am a designer, and believe me, I
wouldn't be involved in the project if I didn't think it was. I just
want to make sure that we're not turning the process of installing a
font into an interactive question and answer session when it doesn't
seem like it has to be. The truth is, the great majority of people
who would use GNUstep/Etoile would likely never be concerned with how
their fonts are grouped together... and I don't want to slow up their
lives by forcing them through a package editing process every time
they add a new font.


J.


0 new messages