[Devel] Re: [Fonts]Another approach to text in X

[Keith Packard]

Around 11 o'clock on Dec 23, David Turner wrote:

>   - a "unified font & type service for Unix", named "UniType" which
>     has been more or less already described in Render mailing list.

I've split Xft into two pieces; one of which (fontconfig) sounds a lot like
UniType:

        o Independent of output technology or rasterization; it's just
          a configuration, customization and matching library

        o Persistant database of existing fonts

        o API is independent of FreeType2, although the implmentation
          uses FreeType2 to examine new fonts

        o Precomputed meta-data, the most important piece being
          the set of encoded Unicode chars.

But, it looks like UniType has some additional features:

>      - identify each installed/available "face" with a _unique_
>        and _persistent_ 128-bit signature.

This seems like it will be useful in transmitting precise face names from 
one application to another, but I'm afraid that font versioning will make
it less useful in transmitting face names from one machine to another.  Is 
there some reason not to trust the font identification built into the 
files as usefully unique?

My plan for 'fontconfig' was to use the names in the files and allow the 
application to discover how close the requested pattern was to the actual 
matched face.  That way the application can discover whether the face 
names and styles matched, or whether some substitution was made.

>          * languages _really_ supported by the face (answering this
>            question is hard !!)

I agree it's pretty hard, but I don't know if it's really needed.  
Applications need to find a face which covers a reasonable portion of the 
document, and then they need to find faces which can fill-in the missing 
pieces, and which match the other faces reasonably well.  Owen Taylor and 
I talked about this at ALS and I think we've figured out a mechanism that 
will work with upper level libraries in a reasonably efficient way.

The idea is to list all of the available faces in 'match' order -- the 
distance from the face to the requested pattern.  Now this list can be 
searched to find a face containing any desired set of glyphs.  Using a 
persistant list built when the font was requested ensures that the order 
is "stable" -- independent of the order in which glyphs are requested.

The reason a single synthetic face can't be exposed from the underlying 
font library is that a document containing passages from different locales 
may well want to use different faces for the same char, depending on the 
context that char is found (think Latin glyphs near Kanji embedded in a 
document that also has pure Latin passages).

Obviously, a trivial synthetic face can be built from this list; simply 
search for the first face holding each glyph.

I think we should push "language" support out of this library, at least 
for now, and focus on describing the Unicode coverage of the faces instead.

>          * list of X11 encodings supported by each face (for
>            backwards compatibility)

Yuck. If applications really need this, let's make them support it 
themselves.

>          * "embedded" versions of some fonts, to avoid re-generating
>            them each time..

Hmm.  I think this conflicts with your goal of being independent of the
rasterizer.  Also, target platforms which really need to avoid the CPU 
cost are also likely to have limited storage, making it unwise to keep 
large numbers of glyph images around.

Perhaps we could consider caching rasterization efforts to share among 
multiple applications; that could be dynamically sized depending on the 
environment.  The Render extension encourages this, I've just not bothered 
to use it as rasterization performance has not been a significant 
bottleneck.

>      - management of system + user + application font list (through
>        pattern matching similar to libXft, or even _directly_ through
>        libXft)

Any library we build will be used by Xft.  Obviously, I'd prefer to use 
the Xft pattern code that I've moved to 'fontconfig', but I don't think 
it's too late to bail on that if we think it advisable.  Opinions on 
whether the Xft pattern stuff could be improved are very welcome.

>    (that's a big difference with libXft that insists that you use FT2 for
>     now).

With Xft split into two pieces, the underlying font configuration 
mechanism does not expose it's own use of FT for this same reason.  Xft 
itself will always expose it's use of FT so that applications can get at 
the native FT API to access more sophisticated parts of that interface.

> then:
> 
>   - A text layout engine, based on UniType, supporting all kinds of
>     sophisticated features (including OpenType, we haven't really touched
>     GX for the lack of fonts to test and interest we ourselves have in the
>     technology).

Yes, keep this separate so that we can get on with solving the font 
configuration and customization issues.  I don't think we can standardize 
on this API yet; the more examples we've got, the more likely we are to 
converge on a good solution in the future.

> I'm now waiting to see more before making a decision on ST, as anyone else..
> In the meantime, I'll continue slowly what I've planned..

I think we should work on the font configuration and customization 
library.  I believe any such work will benefit ST as well as other 
existing font users.  The immediate goal is to standardize how fonts are 
located so that all fonts are available to all applications.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab