[Freetype] Initial comments about Xft

[Juliusz Chroboczek]

Dear all,

While I haven't finished reading the code to Xft yet, I've got a
couple of comments that may be useful to some.

1. The config file

1.1 People have been making comments to the effect that the config
file language is too expressive[1], and therefore difficult or
impossible to process automatically.

I'm not quite sure this is a problem.  The problem is that people have
been thinking of putting all information in a single config file.  But
there's no reason to do that -- the config information could be split
into multiple files, some of which are highly stylised and
machine-processable, some of which are optional and human-editable.

I'm thinking of having three (arguably four) config files on every
single-user system:

(i) the fonts catalogue.  This should contain a boring list of font
name/font file pairs, and be a true cache of information contained in
font files.  It should be possible to add a font file in the relevant
place, and regenerate this file from scratch.

(Issue: is it possible in the current format to associate additional
information to a font file?  In the case of Type 1 fonts, the font
catalogue should contain a pointer to the associated AFM file.)

We should arguably support two fonts catalogues, the system-wide one
and the per-user one.

(ii) the standard font substitution file.  This file should be
provided with XFree86, and contain a list of font substitutions that
do not depend on which fonts are installed.  For example,

  - Arial is a fine substitute if Helvetica cannot be found;

  - a request for family ``Arial'' weight ``Black'' should resolve to
    family ``Arial Black'', weight ``Regular'' (yes, this is an authentic
    example);

  - Times Roman, Times New Roman and Nimbus Roman are fine substitutes
    for each other -- but looping forever if none are available is not
    a good idea;

  - if none of the above can be found, but only then, substitute
    Lucidux Serif.

I am quite positive that the current format can handle the former three;
I'm not sure about the latter.

(iii) the user preferences file, which should be able to override any
system-wide information.  This could contain

  - anti-alias all fonts below 12 pt but above 5 pt;

  - I'm a deviant; systematically substitute Helvetica with Zapf Chancery.

Only the fonts catalogue should ever be touched automatically (from a
cron job?).  All the others should be hand-editable by the user, and
never touched by software.

(Or should user preferences be split into ``gui-friendly'' and
``expert-friendly'' bits?)

One possible implementation would be to have the system-wide config
file include the fonts catalogue as wall as a per-user file, which
would, in turn, include a per-user fonts catalogue and the per-user
preferences.  Other organisations are possible, but at any rate it
looks like the current config file format is expressive enough to
implement the above scheme.


1.2 I still don't understand the matching semantics.  It looks like
there's both a matching (projection) component, and one related to
optimisation (minimisation of errors).  Keith, I'll be glad to write
up some documentation, but you need to give me some hints.


2. The code

2.1 It looks to me like the current API is not quite extensible
enough.  My main issue is the defintion of XftFont.

XftFont implements a disjoint union of core fonts and FreeType fonts
as a ``C'' union and a Boolean for discrimination.  This means that it
is impossible to extend Xft without breaking binary compatibility.

I would like to see XftFont become a private data structure, only
every touched by private accessors.  In particular, I would like to
see:

  - an accessor to determine what the underlying font is (FreeType,
  core, other);
  - a set of accessors to extract the underlying font (one per type of
  underlying font).

I think we should listen to the lesson of XFontStruct, which was made
public and thus prevented us from implementing an efficient data
structure for sparse fonts.


2.2 Ideally, I'd like it to be possible to register additional
backends for Xft.  Thus, an ``underlying font type'' should be one of
an open-ended set of strings, and it should be possible to add one by
saying something like:

  XftBackend foo;

  foo.name = "SuperRenderer";
  foo.open = SuperOpen;
  foo.destroy = SuperDestroy;
  foo.rasterise = SuperRasterise;

  XftRegisterBackend(&foo);

The mechanism should be flexible enough to allow:

  - using a rasteriser for a new font format;

  - ``wrapping'' the Xft functions (e.g. supporting reordering of
    glyphs in a font);


2.3 I've got a few nits with naming of encodings in xftfreetype.c.  It
looks like Xft uses ``adobe-fontspecific'' where the core backends use
one of ``adobe-fontspecific'', ``microsoft-symbol'' or
``adobe-symbol''; I think Xft should accept all three names.

Additionally, Xft uses ``glyphs-fontspecific'' where the TrueType core
backend uses ``truetype-raw''.  I have no problem with adapting the
TrueType backend to the Xft convention -- unless Keith prefers to do
the opposite.


I suggest that replies to this e-mail should go to fonts at xfree86.org.

See youse when I've understood some more,

                                        Juliusz



[1] It's not Turing-complete, though.  It looks like all config files
terminate.