There doesn't appear to be a good reason to abort when 'v1' has type
FcTypeRange. If there does turn out to be a good reason for this then it
should be better documented and the code for handling this case removed.
At worst it seems -1 should be returned as it is for other unknown
types. It is possible this is left over debug code from the initial
implementation.
Found by Clang-Tidy. The intent seems to have been to skip all leading
whitespace in the 'style' string, but instead this loop was an odd
looking no-op. Remove the 'break' from the loop so that it will
continue until end of string or a non-space character is found.
There seems to be a lot of config files using fullname property in the world.
To keep the backward compatibility, fullname property is back to a cache at
the scan matching phase but will be rebuilt once it is done according to family
and style property in the pattern no matter what changes one made in fullname
property during that.
Ref. https://bugzilla.redhat.com/show_bug.cgi?id=1902881
Instead, when building with Visual Studio-style compilers, define 'FcPublic' as
appropriate so that symbols will be exported without the need to maintain a
.def file.
To work around a warning with GCC10 on Win32
warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=]
Before this change building with ThreadSanitizer and running
test/test-pthread generated a large number of threading issues. These
mostly stemmed from fc_atomic_ptr_get not doing an atomic load and using
"acquire load" instead of "load acquire". After making these changes it
was still necessary to use fc_atomic_ptr_get where it was needed.
This also documents the current memory barrier requirements for the
atomic primitives.
OpenType spec says that the Regular descriptor would generally be
omitted from fullname. but some fonts doesn't follow on it.
So decided to construct a fullname from family and style instead of
relying on the meta data in a font.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/208
We were using the family names from the pattern without
copying, and this was leading to a valgrind warning:
==53167== Invalid read of size 1
==53167== at 0x58B0238: FcStrCaseWalkerNextNonBlank (fcstr.c:198)
==53167== by 0x58B0238: FcStrCaseWalkerNextNonBlank (fcstr.c:186)
==53167== by 0x58B02C7: FcStrCmpIgnoreBlanksAndCase (fcstr.c:281)
==53167== by 0x58A4D44: FcHashTableFind (fchash.c:109)
==53167== by 0x5895E76: FamilyTableAdd (fccfg.c:1634)
==53167== by 0x589646A: FcConfigAdd.isra.0 (fccfg.c:1823)
==53167== by 0x58988CF: IA__FcConfigSubstituteWithPat.part.0 (fccfg.c:2228)
==53167== by 0x55F4F1A: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:106)
==53167== by 0x5B88AF6: pango_fc_default_substitute (pangofc-fontmap.c:1795)
==53167== by 0x5B88D15: pango_fc_font_map_get_patterns (pangofc-fontmap.c:1850)
==53167== by 0x5B88FC7: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1952)
==53167== by 0x5623627: pango_font_map_load_fontset (pango-fontmap.c:161)
==53167== by 0x5621743: pango_context_get_metrics (pango-context.c:1782)
==53167== Address 0x150d3450 is 0 bytes inside a block of size 10 free'd
==53167== at 0x483B9F5: free (vg_replace_malloc.c:538)
==53167== by 0x58ABE70: FcValueListDestroy (fcpat.c:147)
==53167== by 0x5898A08: IA__FcConfigSubstituteWithPat.part.0 (fccfg.c:2203)
==53167== by 0x55F4F1A: pango_cairo_fc_font_map_fontset_key_substitute (pangocairo-fcfontmap.c:106)
==53167== by 0x5B88AF6: pango_fc_default_substitute (pangofc-fontmap.c:1795)
==53167== by 0x5B88D15: pango_fc_font_map_get_patterns (pangofc-fontmap.c:1850)
==53167== by 0x5B88FC7: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1952)
==53167== by 0x5623627: pango_font_map_load_fontset (pango-fontmap.c:161)
==53167== by 0x5621743: pango_context_get_metrics (pango-context.c:1782)
Use copies of the strings as keys in the hash table to avoid this.
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.
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
Right now fontconfig uses a cache found first in a path and
cachedirs are the order of the system-wide path and then the user path.
this is due to avoid writing caches into the user path when running as root.
However, changing caches by certain config only, e.g. using <match target="scan">
may not take effect by this behavior, because it may be stored into the user path.
Thus, needing to find the latest cache out from paths.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/182
When loading the default config file with FONTCONFIG_SYSROOT,
it fails if no /etc/fonts/fonts.conf is available, even if it is
there where is based on sysroot.
To address this, FcConfig is required to determine the sysroot.
therefore, this change makes FcConfigFilename() deprecated,
use FcConfigGetFilename() instead.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/181
cachedir is used to determine where cache files are stored.
the empty directory will ends up to put them under the top of
directory of XDG_CACHE_HOME. that messes it up and must be avoided.
As a note, if you want to read/write something from the top of
XDG_DATA_HOME (dir) and/or XDG_CACHE_HOME (cachedir),
put "." instead of the empty.
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/180
In some cases, non-English languages might appears first in current order.
and when having English name with non-English language ID like Google Noto CJK TC,
English name with English language ID will be dropped due to duplicate.
This fixes that issue.
Most of functionality should be moved to FcFreeTypeQueryAll()
for varfonts now though, if doing the same to FcFreeTypeQuery()
returns Null pattern because of inappropriate masking.
This might be not that big deal for varfonts support. but
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/162
Reported by Kevin Scott
'salt' attribute affects a cache filename to generate different name from directory name.
This is useful when sharing caches with host on sandbox and/or give a filename differently:
<dir salt="randomdata">/usr/share/fonts</dir>
<remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir>
Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host.
and write a cache for their own fonts on /usr/share/fonts with different name.
The UUID files would be placed in each font directory to provide the
unique cache name, independent of path, for that directory. The UUID
files are undesireable for a couple of reasons:
1) They must be placed in the font directories to be useful. This
requires modifying the font directories themselves, introducing
potential visible timestamp changes when running multiple
applications, and makes the cache processing inconsistent between
applications with permission to write to the font directories and
applications without such permission.
2) The UUID contents were generated randomly, which makes the font
cache not reproducible across multiple runs.
One proposed fix for 2) is to make the UUID dependent on the font
directory path, but once we do that, we can simply use the font
directory path itself as the key as the original MD5-based font cache
naming mechanism did.
The goal of the UUID file mechanism was to fix startup time of
flatpaks; as the font path names inside the flatpak did not match the
font path names in the base system, the font cache would need to be
reconstructed the first time the flatpak was launched.
The new mechanism for doing this is to allow each '<dir>' element in
the configuration include a 'map' attribute. When looking for a cache
file for a particular directory, if the directory name starts with the
contents of the <dir> element, that portion of the name will be
replaced with the value of the 'map' attribute.
Outside of the flatpak, nothing need change -- fontconfig will build
cache files using real directory names.
Inside the flatpak, the custom fonts.conf file will now include
mappings such as this:
<dir map="/usr/share/fonts">/run/host/fonts</dir>
When scanning the directory /run/host/fonts/ttf, fontconfig will
use the name /usr/share/fonts/ttf as the source for building the cache
file name.
The existing FC_FILE replacement code used for the UUID-based
implementation continues to correctly adapt font path names seen by
applications.
v2:
Leave FcDirCacheCreateUUID stub around to avoid removing
public API function.
Document 'map' attribute of <dir> element in
fontconfig-user.sgml
Suggested-by: Akira TAGOH <akira@tagoh.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This saves the value of FONTCONFIG_SYSROOT in the config instead of
having to call getenv every time we need this value.
This also uses 'realpath' to construct a canonical path to sysroot,
eliminating symlinks and relative path names.
Signed-off-by: Keith Packard <keithp@keithp.com>
Szunti
Ben Wagner
Akira TAGOH
Niklas Guertler
Chun-wei Fan
Xavier Claessens
Matthias Clasen
Jan Tojnar
Tim-Philipp Müller
Alan Coopersmith
Mathieu Duponchelle
Jonathan Kew
Nirbheek Chauhan
Egmont Koblinger
Keith Packard