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.
Some systems build FreeType using CMake rather than autotools (such as Visual
Studio), which will give us CMake config files rather than pkg-config files, so
if we can't find FreeType using pkg-config, try again using CMake.
Please note that according to FreeType's docs/VERSIONS.TXT, the version we want
when checking with CMake is 2.8.1 or later.
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.
Recently some python scripts has been added to the build toolchain for meson build support. but we don't want to maintain multiple files for one purpose. since autotools build support will be guradually discontinued, integrating those scripts into autotools would be better.
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.
Ben Wagner
Akira TAGOH
Niklas Guertler
Chun-wei Fan
Nirbheek Chauhan
xiota
Tim-Philipp Müller
James Lee
Xavier Claessens
Matthias Clasen