[Fontconfig] Streamlining fontconfig scanning

[Behdad Esfahbod]

n Wed, Aug 9, 2017 at 7:51 PM, Keith Packard <keithp at keithp.com> wrote:

> Behdad Esfahbod <behdad at behdad.org> writes:
>
> > I understand why it was added, but hoping that many many years later, we
> > can actually remove it and call font bugs what they are: bugs.
>
> Yeah, I can definitely agree on that -- the majority of the fonts I
> found with trouble were clearly subsetted and sold for cheap. The
> problem is that these fonts over-represent the languages they support,
> and you end up with blanks where characters should be. Of course,
> picking fonts by language support is not something we usually want to do
> with display fonts anyways, so maybe the bugs won't have that much
> negative impact.


I thought about this more.  I don't think in reality this will be a
problem.  For language-driven selection, we typically have good aliases set
up.  My gut feeling is that the problem is more with extended Latin fonts,
not other scripts.  I came up with ideas for keeping the old behavior while
benefiting from the speedup.  That said, we have to decide whether the
previous behavior is desired or not.  As Khaled pointed out, many advanced
fonts can benefit from mapping to an empty glyph and transforming it in
GSUB/GPOS...  I like allowing that.

Anyway, here's some ideas for how to keep things fast while allowing for
blank checks:

  - Previous code was super slow on color-emoji fonts since it was loading
all PNGs.  Well, the outline check only applies to outline fonts.  So, for
bitmap, no loading is good,

  - If font is not CFF or TrueType, fallback to loading.  This should
handle Type1, etc, which I personally don't care about.  Alternatively, if
those are not usually problematic, skip.

  - If Latin1 characters are particularly concerning (eg. the cheap subset
category), we can always check for Latin1 chars only.  That still keeps the
huge performance boost on larger fonts.

  - Assume CFF fonts are sane.  For TrueType, we can keep my 'loca' table
check.  That detects all empty simple glyphs (but not composites) and was
practically free in terms of measurable timing.  If and only if the loca
check found an erratic glyph (ie. non FcBlank char having empty
simple-glyph) then we do a full FT_Load_Glyph() check.  This should keep
good fonts performant while taking care of bad fonts.

  - If CFF is so important to check, we can implement the same check as
'loca', using the CharString INDEX of the CFF, but that one is much harder
to get hold of, so I'm willing to wait and see if CFF is a problem at all.

Anyway, we need to reach a rough consensus on which direction to go with
this.  While the checks above sound smart, I have a hunch that keeping it
simple results in less headache in the long term.

b


-- 
behdad
http://behdad.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20170809/40f4899f/attachment-0001.html>