When a config file is symlinked and obtaining an relative path from it for <dir>,
it behaved like:
$ realpath /path/to/foo.conf
/path/to/realpath/foo.conf
$ FONTCONFIG_FILE=/path/to/foo.conf fc-cache -v
Font directories:
/path/to/fonts
/path/to/fonts: skipping, existing cache is valid: 1 fonts, 0 dirs
/path/to/cachedir: cleaning cache directory
fc-cache: succeeded
And after this change:
$ FONTCONFIG_FILE=/path/to/foo.conf fc-cache -v
Font directories:
/path/to/relpath/fonts
/path/to/realpath/fonts: skipping, existing cache is valid: 1 fonts, 0 dirs
/path/to/cachedir: cleaning cache directory
fc-cache: succeeded
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/290
Before this fix:
$ fc-match :postscriptname=LiberationSans
LiberationSansNarrow.ttf: "Liberation Sans Narrow" "Regular"
After this fix:
$ fc-match :postscriptname=LiberationSans
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
See https://bugzilla.redhat.com/show_bug.cgi?id=1946871
The argument passed to each thread in test-pthread.c indicates a thread
number to report when finished. This value is read out by the thread
into a local variable early in the thread's execution. Currently, the
address passed as this argument is the address of a loop local. However,
it is possible that the created thread will not be scheduled to run or
will not read the argument before the thread creation loop finishes and
the local is destroyed. This can lead to odd behavior, usually observed
as multiple threads reporting the same thread_num.
Fix this issue by storing the thread arguments in a parallel array to
the array of threads. This ensures that the thread arguments are in
scope as long as the threads themselves.
Discovered with tests/test-pthread with AddressSanitizer enabled.
If two threads attempt to create the FcCache lock in lock_cache at the
same time, both threads may create and initialize a local FcMutex. One
thread will atomically make cache_lock point to its FcMutex. The other
thread currently calls FcMutexFinish on the local lock, but does not
free it. Change this behavior to free the unused lock.
Found with test/test-pthread on an LeakSanitizer enabled build.
Reduce the strength of the C11 atomics from memory_order_seq_cst to the
actually required memory order constraints for each operation. In
addition to reflecting the already documented memory order constraints,
this should allow for better code generation.
Bump the cache version to avoid unexpected behavior in
older version of fontconfig.
There was no real incompatible features introduced in a cache.
But the older version of fontconfig can't deal with variable fonts
and then it failed. To avoid this breakage, you may want to choose
one of options like:
1) Applying this change to fontconfig in host and remove all the
fontconfig caches and then regenerate them by fc-cache linked with
older one and new one. or simply run applications.
You'll see two versions of caches in the cache directories.
2) Remove variable fonts on system and remove all the fontconfig
caches too. then regenerate caches. You'll still see one version of
caches there but without the entries of variable fonts.
After that, the problem should be gone.
https://bugzilla.redhat.com/show_bug.cgi?id=1981500
If the `realloc(numbers)` call fails, shrinking the leaves allocation
back to the old size is not guaranteed to return the old pointer value.
While this might be the case with some malloc() implementations, realloc()
could also just mark the following area as free.
To make this less error-prone, we grow numbers first and then grow leaves
since the numbers content does not need to be relocated, but leaves does.
See https://bugs.freedesktop.org/show_bug.cgi?id=90867
This fixes deprecation warnings when building for macOS >= 10.12 systems.
Additionally, using stdatomic.h (or the more modern __atomic_ builtins)
is required when targeting CHERI-enabled architectures such as
CHERI-RISC-V or Arm's Morello since the compiler rejects __sync_* atomic
for pointer types (they only work with integers).
When targeting CHERI, casts between pointers and integers must use
(u)intptr_t. uintptr_t values contains pointer bounds (and additional
metadata), whereas other integer types do not. This change also adds a
cast to FcOffsetToPtr() to silence a compiler warning that triggers if
the compiler cannot statically infer which side of an arithmetic operation
is the pointer operand and which one is the offset/mask.
Reverts the part of 6def66164a that
removed the fc_atomic_ptr_cmpexch compatibility code for systems earlier
than Mac OS X 10.5.
Reverts the part of 447b9ccc7d that moved
the definition of fc_atomic_ptr_get into the Mac OS X > 10.4 block. That
code is still needed on 10.4 and is implemented using functions that are
available on 10.4.
Compare against MAC_OS_X_VERSION_MIN_REQUIRED using a number not a
constant because the constant is not available on earlier SDKs.
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.
Akira TAGOH
Ryan Schmidt
Ben Wagner
Alex Richardson
Mehdi Sabwat
Albert Astals Cid
Heiko Becker
Tim-Philipp Müller
Xavier Claessens
Carmina16
Szunti
Jacko Dirks
ratijas