[Fontconfig] Revisiting FcFontMatch and FcFontSort

[Werner LEMBERG]

> 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