Non-string values in a cache is supposed to choose one from them.
Due to the change of da1c9f7a, there was a regression on scoring for
matching functions. So reverting the behavior for evaluating non-string
values to the previous one.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/286
Sometimes fonts has multiple values in family and sub-family in order to unify
other variants into one. they basically make difference in sub-family though,
they also still have standalone family and sub-family. in that case, sub-family is
likely to be Regular.
fontconfig couldn't recognize the difference between :family=Foo:style=Regular
and :family=Foo Caption:style=Regular for example because fontconfig didn't
give different score on matching result for the position of multiple values in
a cache.
Thus, when querying a font like :family=Foo:style=Regular may results
:family=Foo Caption:style=Regular. (see the test case for more details)
To fix this situation, giving different score according to the position
of multiple values in a cache as well as the position of multiple values
in a query.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/283
sysconfdir defaults to /etc when the prefix is set to /usr. But joining
MESON_INSTALL_DESTDIR_PREFIX and sysconfdir when the latter is an
absoulte path, results in sysconfdir only. Which might lead to an error
during install because /etc/fonts/conf.d/ might already exist from an
pre-existing fontconfig installation.
In Makefile, we are trying to remove old symlinks first and then create a symlink.
do the same thing in meson too.
Also, the line of the exception handling for FileExistsError is meaningless
as the above line is taking care of it instead and we shouldn't ignore it if
os.remove and os.symlink doesn't work somehow.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/275
commit ae9ac2a1 from !165 introduced a regression when
fontconfig is built as a subproject. In that case we
would fail to correctly construct the path to the root
build dir where the meson-info subdirectory resides,
instead looking for it in the fontconfig subproject
subdir. This would result in
FAILED: subprojects/fontconfig/src/fcobjshash.gperf
errors in the cutout.py script.
Instead use the @BUILD_ROOT@ substitution to get
to the build root which will work correctly in
either scenario.
Discovered by AddressSanitizer. When left_o and right_o are promoted the
promoted values are placed on the stack in FcValuePromotionBuffer.
The FcValuePromotionBuffers must then continue to be in scope while
left_o and right_o point into their content. In 9d4e5d0f the
FcValuePromotionBuffers were moved into the incorrect scope, leaving
left_o and right_o pointing into an object whose lifetime has ended.
This is similar to left and right which appear to have a smaller scope
but are actually required to be in the larger scope.
Correct this by moving the FcValuePromotionBuffers to the proper scope.
Leave the left and right FcValues where they are since they are in the
correct scope already.
This also adds to test-conf the ability to create charset, langset,
range, and matrix in patterns. This allows for a simple test which fails
under AddressSanitizer before this change and passes after.
Pass c_args to the compiler when preprocessing the gperf header file,
they might contain important bits without which compilation/preprocessing
might fail (e.g. with clang on Android). cc.cmd_array() does not include
the c_args and we can't easily look them up from the meson.build file, so
we have to retrieve from the introspection info.
This is basically the Meson equivalent to commit 57103773.
Passing -Wno-pointer-bool-conversion in cross file
to suppress compiler warning:
src/fcfreetype.c:1373:11: address of array 'os2->achVendID' will always evaluate to 'true'
fcformat.c:762:44: warning: expression which evaluates to zero treated as a null pointer constant of type 'FcChar8 *' (aka 'unsigned char *') [-Wnon-literal-null-conversion]
if (!FcNameUnparseValue (buf, &l->value, '\0'))
^~~~
fcformat.c:769:38: warning: expression which evaluates to zero treated as a null pointer constant of type 'FcChar8 *' (aka 'unsigned char *') [-Wnon-literal-null-conversion]
FcNameUnparseValueList (buf, l, '\0');
^~~~
Correct the type of TestMatchPattern's 'ret' from TestResult to
TestMatchResult to match the actual return type (and values assigned to
it).
Fix leak of TestMatchPattern's 'xml' and TestFamily's 'pat'.
Simplify TestMatchPattern cleanup and ensure cleanup always happens.
Any early out checks must give the same answer as FcConfigCompareValue.
An accelerator was added for family names which treated all ops as if
they were FcOpEqual, giving the wrong answer for other non-equivalent ops
(for example FcOpContains or FcOpNotEqual).
This adds a test which passes before the accelerator was introduced,
fails after, and will pass again after !142 lands. This tests the all
not_eq case.
The test-conf build_pattern attempted to convert known constant strings
into integer values. However, it did so by always converting the string
value to an integer if possible and then complaining if the key wasn't
of the expected type. This lead to error messages on "style": "Regular"
since "Regular" was recognized as "weight".
Instead, only attempt conversion from string to integer if the key is
the name of an object which can take an integer type. This eliminates
the spurious non-fatal errors reported when parsing
test-90-synthetic.json.
This also fixes an issue where the created value was given the type of
the object found, but the integer field was assigned. Instead, check
that the object type can take an integer and always set the value type
to integer.
The test-conf test requires libjson-c to be available in order to be
built. However, there has been no user indication that additional tests
could be built if the json-c development files were available.
Continue to not build test-conf if json-c is not available, but do run
the test harness. The test harness is updated to SKIP the test if the
test-conf binary is unavailable.
Reported by AddressSanitizer when running test-conf. The `query`,
`result`, and `result_fs` were not initialized to NULL so could result
in a wild free when first initialized.
The `method` was also not initialized to NULL so comparisons could be
made against random data if it had not yet been assigned.
The outer `fs` was never destroyed, but is also not used, so remove.
Posix says:
The condition can be EXIT, 0 (equivalent to EXIT), or a signal
specified using a symbolic name, without the SIG prefix, as listed
in the tables of signal names in the <signal.h> header defined in
the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 13,
Headers; for example, HUP, INT, QUIT, TERM. Implementations may
permit names with the SIG prefix or ignore case in signal names as
an extension.
Remove 'SIG' from trap conditions in run-test.sh for portability.
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
Ryan Schmidt
Akira TAGOH
Mehdi Sabwat
Albert Astals Cid
Heiko Becker
Tim-Philipp Müller
Ben Wagner
Xavier Claessens
Carmina16
Szunti
Jacko Dirks
ratijas