"color" property has a value more than 1 because the value of FT_HAS_COLOR
is directly set to it. this seems breaking the behavior of FcFontList with FC_COLOR=true
because it is more than FcDontCare.
So changing comparison that way.
Because FcDirCacheDeleteUUID does not reset the modification time on
the directory, and because FcDirCacheRead unconditionally creates the
UUID file each time it is run, any empty directory in the cache will
get its timestamp changed each time the cache for that directory is
read.
Instead, just leave the UUID file around as it is harmless.
The alternative would be to only create the UUID file after the cache
has been created and the directory has been discovered to be
non-empty, but that would delay the creation of the UUID file.
Signed-off-by: Keith Packard <keithp@keithp.com>
GPerf seems not allowing the empty lines though, current recipes are supposed to drop them.
but seems not working on some env.
So taking the proper way to do that instead of incompatible things against platforms.
FcFontSetFont() accesses fs->fonts in that macro though, there was no error checks
if it is null or not.
As a result, there was a code path that it could be a null.
Even though this is unlikely to see in usual use, it might be intentionally created
in a cache.
So if fs->fonts is a null, we should consider a cache is invalid.
FcConfigRealFilename() follows symlinks, but the link may be relative to the
directory containing the link. For example, on my system, I have this file:
/etc/fonts/conf.d/99-language-selector-zh.conf ->
../conf.avail/99-language-selector-zh.conf
Since /etc/fonts/conf.d is probably not in PATH, open()ing the file would fail.
This change makes FcConfigRealFilename() return the canonicalized filename
instead. So for the example above, it would return:
/etc/fonts/conf.avail/99-language-selector-zh.conf
This was causing bad font rendering in Chromium [1] after the regression I
introduced in 7ad010e80b.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=857511