Re: Debian font registry? [ long ]
Branden Robinson <branden@ecn.purdue.edu> writes:
[...]
> Anyway, to your points:
>
> > - How does a user specify a font without becoming an expert
> > in X. This is already an issue normally, but becomes a big
> > issue when i18n comes into the picture. Because if you
> > are rendering internationalized text, 'Helvectica' doesn't
> > map to a single XLFD but to a set of XLFDs. (fontset)
>
> Well, I don't have a GUI form designer handy, but I imagine an X client
> could have a font selection dialog box that looks much like ones in
> Windows, except it has more fields that can be changed. There are
> something like 13 components to an LFD name. The parts that are too
> daunting or too seldom-used by the casual newcomer could always be tucked
> away in a separate dialog accessed by an "Advanced..." button, or the font
> dialog could be a tab book, etc. etc.
You should take a look at the GTK+ font selection dialog. If
you have GNOME installed, you can bring it up with gfontsel.
I think with the first page of this widget, Damon Chaplin did an
almost ideal job of making XLFD's nice for users:
- It omits the foundry when the family name is unique
- It combines the style fields in a readable way
- It hides scaled bitmap fonts by default.
Unfortunately, it falls apart when you throw internationalization
into the picture.
If you have a fonts in a good selection of different encodings
selected, go to 'Fixed (misc)'. The average user, whether in the
US, or in Tibet, is not going to be able to make sense of this
mess.
Now, in fact, what gtkfontsel is doing is not ideal. Instead of
making the user deal with the encoding, it should be creating
a fontset out of all the fonts that differ in only encoding:
So, instead of forcing the user to choose betwen:
-misc-fixed-medium-r-normal-*-*-*-*-*-c-*-is13194-devanagari
-misc-fixed-medium-r-normal-*-*-*-*-*-c-*-iso646.1991-irv
It should be creating a fontset that looks like:
-misc-fixed-medium-r-normal-*-*-*-*-*-c-*-*-*
However, this doesn't really solve the problem, because all
fonts that a user would want in a fontset don't actually have
the same family/encoding; for instance, the appropriate Japanese
equivalent of the above is:
-jis-fixed-medium-r-normal-*-*-*-*-*-c-*-jisx0208.1983-0
And it gets more complicated from there. (The fontset used
in GTK+ for Korean is:
-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*,
-*-gulim-medium-r-normal--*-120-*-*-*-*-ksc5601.1987-0,
-*-kodig-medium-r-normal--*-120-*-*-*-*-ksc5601.1987-0,
-*-*-medium-r-normal--*-120-*-*-*-*-ksc5601.1987-0,*
)
Also, note that the range of styles and sizes available
for each encoding for misc-fixed varies greatly.
Appropriate aliasing does help this problem - that is,
I don't actually need to know that iso-8859-2 font
Helvatica-like font on my system is:
-biznet-aplos-medium-r-normal-*-*-120-*-*-p-*-iso8859-2
Because there is a convenient alias to -adobe-helvetica-...
The two problems with X aliasing are:
1) It isn't possible to create mixed-size collections
of fonts - scaling of bitmaps for 16-bit fonts
is to be avoided at all costs; in some contexts, you
want to use 12 point roman fonts, but if you encounter
Japanese characters, use 16 point fonts.
2) It leads to an explosion of names, decreasing useability.
When the user is confronted with a dialog box which
includes:
Aplos
Helvetica (cronyx)
Helvetica (adobe)
and selecting all of those gives the same result for
ascii, but only Helvetica (adobe) actually displays
the correct accents for French and for Hungarian...
The automatic-reencoding that is going into XFree86-4.0
will help this ... since at that point only a iso10646
font needs to be installed and the different fonts can
be autogenerated form it, giving consistency between
encodings for the core fonts that isn't there now.
> When all else fails there is always the alias mechanism. When there are no
> collisions this works fine. I'm not sure it makes a lot of sense to tackle
> the issue of preventing alias collisions, or of providing "simple" font
> names that are easily typed on a command line -- not if we're shooting for
> an "easy for the end user" goal. They won't be specifying font names on
> the command line anyway. The more esoteric parts of the LFD can be tucked
> away in a GUI. An application can always construct the full LFD internally
> and I don't see any reason for the whole big ugly string to ever be
> presented to the user unless he wants to see it.
>
> At first glance, I can see a casual user wanting to manipulate foundry,
> family, weight, slant, point size, registry, and encoding. The latter two
> probably aren't important for North Americans but they are for the rest of
> the world. Other stuff like spacing and average width are often fixed
> anyway for a particular font (especially BDF ones), or are only used by
> people doing stuff more on the typesetting end of things, rather than word
> For.
The biggest problem with XLFD's to my eye is not from the GUI
perspective - with a bit of appropriate aliasing, and a chunk
of internal magic (GtkFontsel is almost 4000 lines of code), it
should be possible to create a GUI that allows the user to
choose a fontset that works passibly for their locale.
The problem is specifying fonts from programs in a way that
is going to produce good results on all systems in all
locales.
Nowdays, a developer generally just uses ?fontsel to pick
a plausible looking XLFD, adds a few more wildcards, and
hopes it works.
GTK+ has a mechanism (/etc/gtk/gtkrc.$LANG / ~/.gtkrc.$LANG)
for specifying different default fontsets for different locales,
though there is currently no way of specifying
Here is the default sans-serif fontset
Here is the default serif fontset
Etc.
Qt has a different mechanism. (I don't know the details -
the Japanese patches for Qt 1.4 used ~/.qt18nrc or something).
Having this configured systemwide in a standard fashion,
could reduce the pressure to provide default fontsets
that work everywhere with any random combination of
fonts installed.
The next version of GTK+ (which will have as a main feature
extensive unicode support - for some rough information about
the underlying toolkit-independent layer see
http://people.redhat.com/otaylor/gscript/),
will probably hide XLFD's from the programmer in most cases.
> processing the real diehard typesetting folks X fonts are probably
> insufficient anyway. They want DPS.
Well, as far as fonts goes, DPS is 10-15 years behind the
times. OpenType is pretty nice, and there is some interest
I think in providing that in an X extension (possibly as
OpenType/CFF - so Type1 outlines instead of the
patent-encumbered TT outlines.)
In some sense, my interest is in providing a programmatic and
user interface that can either be provided on top of current
X fonts, or on top of something better - postscript printing,
client side rendering, or an X extension.
This is one way where the question of font naming interacts
with the question of a repository for fonts. If I see a
.pfb/.pfm in /usr/share/fonts/default/Type1, there should
be a standard way of figuring out which XLFD it corresponds
to.
> I guess what I am asking is, what need do you want to fulfill with this
> initiative?
> > > What kind of text database were you thinking of? If it's just a list of
> > > LFD names then the fonts will be served through a font server (be it
> > > internal or external to the X server) and you can either use programs like
> > > xlsfonts or Xlib calls to accomplish the same thing.
> >
> > Certainly. (Though the performance of xlsfonts equivalents is actually
> > a fairly big bottleneck in a lot of cases.)
>
> This I was unaware of. Perhaps they are not written efficiently? Or is
> the problem in the underlying Xlib() calls? If the latter, it may be time
> to talk to XFree86. If there are really performance issues, it might make
> sense to author an extension to XFree86 whereby a binary database of
> available fonts can be generated within the X server or font server and
> exported to client apps that want to keep track of it themselves. The X
> font database is static most of the time, so it makes sense to optimize for
> access, not record updates. LDAP springs to mind for no good reason so
> please shoot me now. :)
Well, the problem is just that there is a lot of information being
moved around. Though looking at it, it isn't as much of
a bottleneck as I had remembered. At least locally / over fast
networks / on fast machines, we are talking < 0.1 seconds to
query a list of all fonts.
> Implementation details aside, if performance of shoveling lists of font
> NAMES around is a big deal, I'm sure it is an addressible issue. XFree86
> is currently hammering on ideas about shipping around the fonts themselves,
> especially iso10646 varieties which may have tens of thousands of glyphs.
> They're active on the subject of fonts right now so it might be a good time
> to talk to them.
Looking at what I had remembered as slow, it is more getting the
information about supported glyph ranges for each font, so there
clearly is a need for efficiency there. I'm on the relevant mailing
lists, though I've been quiet so far.
[...]
> Upon further reflection I'm not sure the demand for font name
> simplification is really there. Like I said above, a GUI makes it easy to
> hide hairy details from the user. As far as the repository goes, well,
> that's really just a filesystem layout kind of thing and it shouldn't take
> too much brainpower to come up with something reasonable.
I'm not sure yet if it exists at the system configuration level.
I do believe that it is necessary at least at the programmatic
level, and I think it would be good if the mapping from
XLFD's to the programming/UI level was standardized.
Regards,
Owen
Reply to: