Make FcConfigPromote use a switch instead of
an if-else cascade, and avoid calling it when
we can.
Note that we need to add a case for integers
in FcConfigCompareValue, since we are no longer
promoting integers to doubles unconditionally.
When we don't need to differentiate between weak and strong,
we can exit the loop in FcCompareValueList once we found a
best match.
This change helps reducing the amount of list walking we do
for fonthashint, where careless config files end up creating
lists with ~100 booleans :( We don't want to walk all those
to the end, over and over again.
We are already special-casing family, and the only other case
where weak != strong, PostScript names, doesn't have long lists
of values, so the limitation to weak == strong doesn't matter
much in practice.
When checking whether a test matches a pattern,
we cut the loop short for FcQualAll when we see
the first non-matching value, but for FcQualAny
we were always walking the full list. This patch
cuts the loop short for FcQualAny when we see the
first matching value.
With the way typical font configurations look, matching the lists
of families is the bottleneck for both FcFontMatch and FcFontSort.
After installing the Noto fonts on my system, an innocent match
pattern like "Cantarell 14" turns into a monster with a list of
300 family names after calling FcConfigSubstitute().
With this setup, every FcFontSort call takes 80-100 ms, which is
entirely incompatible with using FcFontSort for anything interactive.
And many font choosers render every font in itself, causing on average
one FcFontSort call per font.
On my system, it takes more than 20 seconds to open the GTK font
chooser dialog, with frequent stalls when scrolling.
This patch special-cases font families and replaces the list
walking for comparison with a hash table lookup. With this
patch, the FcFontSort time goes to ~10ms per call. Which is
still not good enough for calling it dozens of times when
scrolling, but a significant improvement.
Add a hash function that behaves like family
comparison: ignoring case and blanks. This
will be used to replace the list walking for
finding family matches with a hash table.
Make variants of FcStrCaseWalkerNext for the two
common cases, delim == NULL and delim == " ", to
speed things up.
These are inner loops, and having the conditions
as simple as possible helps.
As far as I can tell, fontconfig can recover from encountering an unknown attribute.
And unknown elements already print a warning instead of an error, so let's make this a warning too.
"fontversion" used to be modified to sort out fonts as a technique.
But that lost the original purpose to do the version control between
releases.
This change adds the dedicated property into the cache.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/226
mtime isn't reliable to detect updates of fonts on OSTree based system
since they reset mtime to 0 for system files.
Due to this, there are the situation likely to happen where mtime is
newer but content is older.
Fortunately, OSTree based system requires reboot to deploy changes. so
we can assume we won't see any changes on system fonts. so system caches
are always up-to-date. we can ignore meta data for system fonts in
user caches.
XML tools interpret “fonts.dtd” as a relative path.
Unfortunately, that can not work now that the configuration is spread over
multiple system-dependant directories, without a common relative path to this
file. And, an absolute path can not be defined in a system-independant way.
System independance is a requirement to share config files between systems.
Therefore, replace the broken relative path by a formal URN, that will work the
same way on all systems, without network access.
This makes the DTD registerable with commands like:
$ xmlcatalog --noout --add system \
"urn:fontconfig:fonts.dtd" \
"file:///usr/share/xml/fontconfig/fonts.dtd" \
/etc/xml/catalog
That enables easy config file checking:
$ xmllint --loaddtd ${config_file} >/dev/null
The previous fix in fbc05949ef was wrong. reverting.
When reading older caches, FcDirCacheMapHelper() returns FcFalse and
it became the return value from FcDirCacheProcess() too, which is wrong.
Actually one of calls for FcDirCacheMapHelper() should be successfully
finished and closure should have a valid pointer for cache.
Due to this, the proper finalization process wasn't running against
cache in closure.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/227
iPhone 2.1 was released a long time ago, and the macro for checking
the target iOS SDK version has changed. We can simplify everything and
do a very basic check.
Due to the unproper initialization of `latest_mtime', the duplicate caches
was still in fcCacheChains with no references. which means no one frees
them. thus, the memory leak was happened.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/227
Matthias Clasen
Akira TAGOH
Jan Tojnar
Tim-Philipp Müller
Alan Coopersmith
Ben Wagner
Mathieu Duponchelle
Jonathan Kew
Nicolas Mailhot
Nirbheek Chauhan