Keith Packard wrote:
> ...
> I'm considering whether font merging would be useful in Xft. Once I've
> finished adding the Unicode coverage information for each font, adding the
> ability to do font merging would be relatively easy. It might extend the
> coverage for simple applications, or it just might encourage people to
> ignore the harder layout issues which Xft will not address.
>
> What do other people think? Should Xft do simplistic merging? Obviously,
> there would be a way to disable this as well.
Mozilla does this and my experience (which I am more than happy
to share) is that it takes a bit of work to choose reasonable
merges. For example:
For a Japanese document, the font matching code should first
look at Japanese fonts not Simplified Chinese, Traditional
Chinese, or Korean fonts. Each language's glyphs are visually
different and WhIlE rEaDaBlE tHe ReSuLtS aRe CoNsIdErEd
UnPlEaSaNt WhEn UsEd In AnOtHeR lAnGuAgE's DoCuMeNt.
While font matching may be done by a layer above Xft, it would
probably help if Xft could render from the list selected from
the layer above. Mozilla implements this by having a list of
fonts, mLoadedFonts, that the measuring/drawing code scans. The
the first font in the loaded fonts list that has a glyph for
the character is used.
The list is built lazily; ie: new fonts are loaded as needed.
Thus fonts are loaded when new characters are measured/drawn
(as a practical matter the upper layer in Mozilla always measures
first so the loaded font list is build during measurment).
Regardless of the order in which character are encountered
the list must always have the same fonts in the same order.
Moz does this by have a place holder for each font regardless
of whether a X font was actually needed (eg: loaded). Thus
the mLoadedFonts list holds the font placeholders and only
when needed is a font is actually loaded into the placeholder.
--
Brian Stell
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
