I'm busy restructuring Xft to handle more stuff and correctly expose a
native Unicode interface. Along this line, I've eliminated the
XFT_ENCODING part of the font pattern; the encoding is *always* unicode
and Xft internally remaps fonts with non-Unicode charmaps. Right now,
that's limited to Symbol and Apple Roman maps which Juliuscz seems to
think is sufficient.
While I still have your attention (I can see it's wandering already), I've
a couple of questions:
Applications need to use unencoded glyphs alongside encoded glyphs,
I prefer not to try to share the same font for these two usages;
for one of the two modes, that will require a lookup per glyph
at rendering time which is currently avoided.
Is it acceptable to require fonts be opened twice, once for the
API to operate in Unicode and once to operate with glyph indices?
Is it sufficient to provide a Unicode to glyph index mapping
function so that applications can open the font un-encoded and
perform their own encoding lookups?
Now for more on what's up inside of Xft.
Xft also stores a complete map of available Unicode characters in the font
pattern; this takes about 1/2 a second to compute for most fonts, so
startup can take a while when you've added a bunch of fonts without
rebuilding the cache manually. This means that you can match fonts based
on Unicode coverage; fonts missing the fewest glyphs in the desired range
match more tightly than fonts missing more of the glyphs.
This is a start on the code needed to build lists of suitable fonts for
presenting a document. Owen and I discussed this at ALS last week and
came up with a tentative plan for making this work. Here's the goal:
1) Start with a font pattern (possibly including multiple family
names)
2) Create an empty list of font names and an empty set of Unicode
coverage
3) For each glyph, check to see if the list of fonts can display
the glyph.
4) If not, ask Xft to extend the list.
5) The list is extended by placing additional fonts which cover
glyphs not yet covered; these are ordered based on the nearness
to the pattern.
As an example, consider a synthetic example:
family coverage
------ --------
Times Latin
Mincho Chinese
Farsi Arabic
The application provies the pattern:
times,farsi,micho-18
An application requests a latin glyph. Xft extends the (empty) list to
be:
List: Total Coverage
----- --------------
Times-18 Latin
Now the application requests a chinese glyph. The list doesn't cover that
glyph, so Xft extends the list incrementally, extending the coverage:
List: Total Coverage
------- --------------
Times-18 Farsi-18 Latin + Arabic
Still no coverage for the chinese, so it's extended one more time:
List: Total Coverage
------- --------------
Times-18 Farsi-18 Mincho-18 Latin + Arabic + Chinese
Now the list covers the requested glyphs. The application can now walk
the list of fonts, preferring the first one in the list which contains the
requested character. This makes the fonts used *independent* of the order
in which glyphs are run through the rendering code.
Because the font patterns themselves contain coverage information, the
extra fonts aren't loaded from disk nor are server resources spent on them,
in fact the storage required for the list will be quite modest -- it's just
a list of existing data.
Taking this of patterns, opening the list of related fonts and selecting
which font is used for each glyph is still the applications problem; any
code down in Xft will only be able to generate ransom note output while
there's a chance that upper levels will do somewhat better.
Alternatively, I can build a matching function which passes each font name
in priority order to a callback which could do whatever it likes; that
would permit this mechanism to be implemented within the application
instead of Xft, and possibly do something different with ordering.
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
