Very slow fc-cache updating on linux

[mtglsk]

Running fc-cache -f -v with han sans takes up to minutes with the font. Never noted such a slow down with other big fonts (like freefont / unifont).

[kenlunde]

How many of the Source Han Sans fonts, and which specific ones, are you trying to install? Also, much of this may depend on what fc-cache is actually trying to perform under the hood. Is it inspecting or traversing the various sfnt tables in the fonts?

Keep in mind that the Source Han Sans fonts push implementation limits in various ways, such as the number of glyphs (65,535 is at the architectural limit, which very few, if any, fonts can claim), a relatively large number of weights (seven, which can multiply the amount of time a process takes), and complex GSUB and GPOS tables. All of these characteristics may expose various inefficiencies in some environments.

I am closing this issue for now, because there is nothing to be done to the fonts, and other environments are able to enumerate these fonts without any substantial lag. But, please provide any additional details for the benefit of others, and me.

[mtglsk]

I decided to try to clean the global cache (/var/cache/fontconfig/*) and run caching again, it seems to speed up a little bit, but nevertheless, this probably is some bug upstream. From my reading it seems that fontconfig checks every glyph to know if there are any empty outlines inside GSUB, could this be the cause of the slowdown? I should probably file a bug upstream... I'm using the large version, btw. I tried each one and there is always a slowdown.

[kenlunde]

It might be useful to post this as an Issue against fontconfig, being sure to provide a reference to the Source Han Sans fonts as a good test case. Checking to make sure that a glyph exists for every GID that is referenced in the 'GSUB' table might indeed be the culprit, considering the extremely large number of substitutions in the 'locl' GSUB feature. One way to test this would be to remove the 'GSUB' and 'GPOS' tables, which can be done by using the AFDKO sfntedit tool. The command line would be as follows:

% sfntedit -d GPOS,GSUB <font>

[behdad]

I have noticed that slowness... Some versions of fontconfig were computing a cryptographically strong hash of the font file. That was extremely slow. We remove that. Even then, the new Adobe CFF rasterizer in FreeType is five times slower than old FreeType CFF rasterizer for loading glyphs unhinted. Fontconfig loads all glyphs to make sure they have an outline...

See:
https://savannah.nongnu.org/bugs/?43248
https://bugs.freedesktop.org/show_bug.cgi?id=64766