n Wed, Aug 9, 2017 at 7:51 PM, Keith Packard <keithp@xxxxxxxxxx> wrote:
Behdad Esfahbod <behdad@xxxxxxxxxx> 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/
http://behdad.org/
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
