[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] Re: [Fonts]Another approach to text in X
From: |
Keith Packard |
Subject: |
[Devel] Re: [Fonts]Another approach to text in X |
Date: |
Sun, 23 Dec 2001 12:17:40 -0800 |
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