<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766#c30">Comment # 30</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Make fontconfig scanning faster" href="https://bugs.freedesktop.org/show_bug.cgi?id=64766">bug 64766</a> from <a class="email" href="mailto:freedesktop@behdad.org" title="Behdad Esfahbod <freedesktop@behdad.org>"> Behdad Esfahbod</a> <pre>(In reply to <a href="show_bug.cgi?id=64766#c22">comment #22</a>) > I added the outline scanning code because we found many font files that were > generated by subsetting a large font with extensive unicode coverage. The > subsetting process would leave the code point map in place and only elide > the actual glyph data. So, the only way we could discover the true coverage > of the font was to look at the actual glyphs. > > If the failure mode was to simply select the wrong font for some code > points, that might be fine. However, the failure mode is instead to display > blank spaces for the missing glyphs. > > These were not hand-hacked fonts, but rather commercial fonts from > semi-reputable font foundaries. The commit when this was added appears to be > lost in time; having occurred in libXft, before fontconfig was split out > back in 2002. > > I'd suggest figuring out if FreeType could return this data faster than by > parsing the whole outline; presumably there's a table present which > indicates where the outline would be and how long it is? Ok, I did a patch to not check outline for CFF fonts and only check the glyph offsets in 'loca' table for TrueType fonts. This has significant speedup benefit mainly because of I/O. It ends up reading less than 5 / 10 percent of the font, so it was a huge boost. This approach correctly takes care of simple TrueType glyphs with no outline. But I found many fonts have composite glyphs that reference a glyph that has no outlines. Currently I can't detect that. Another group was CFF chars mapping to cid1 which has no outline. I might be able to special-case that, but am not very confident about it. As such, I don't think this approach actually works. But even with warm caches it's still a huge speedup. For some 22k fonts: BEFORE real 1m18.376s user 1m12.497s sys 0m3.346s AFTER real 0m18.118s user 0m12.997s sys 0m2.654s That suggests that there's still possible value in speeding up the check either withing FT_Load_Glyph, OR, implementing 'glyf' table access in fontconfig, ignore bitmap fonts, and call into FreeType for CFF fonts. I'll give that a try.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>