> In a recent call, Behdad pointed out a related, but distinct issue
> with the current pipeline approach to font rendering, as implemented
> in pango:
>
> First, pick fonts for all characters ("itemize")
> Second, select glyphs for the resulting runs ("Shape")
>
> The first step is where we use fontconfig to find candidate fonts,
> and then we check their coverage for each character to make a
> choice. fontconfig currently uses freetype to determine coverage
> information for fonts.
>
> But what characters are reasonably 'covered' by font very much
> depends on what use the second step makes of the font. The harfbuzz
> shaper can decompose and compose glyphs and thereby extend coverage
> in ways that freetype has no idea about.
Can you give an example? Normally, the glyph coverage stuff should be
completely internal to a font, hidden behind the cmap table. In other
words, it shouldn't be fontconfig's job to return such information to
the application.
> There are different ways in which this could be improved. One would
> be to give up on the approach of making all font selection choices
> up-front, and instead use a recursive approach in which the shaper
> can ask for more fonts if it can make do with the ones it was given
> initially.
Again, please give an example. It seems to me that you are actually
thinking of improving Pango, not fontconfig per se. I only wonder
whether the approach you are envisioning has drawbacks to applications
that are not using Pango.
> Another, maybe simpler approach would be to make fontconfig use
> harfbuzz instead of freetype for finding font coverage.
I don't object to using harfbuzz – this is what FreeType is actually
using for getting glyph coverage for its auto-hinter. However,
harfbuzz has some quite massive dependencies that might not be wanted
by the user.
Werner
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
