FreeType will return CFF for both SFNT fonts with CFF table as well as
standalone CFF fonts, but applications might want to support the former
and not the later, so now FC_FONT_WRAPPER makes the distinction more
clear.
Currently detects only SFNT wrappers:
- WOFF: if it is FreeType says it is an SFNT font the file starts with wOFF tag
- WOFF2: the same but tag is wOF2
- SFNT: for any other SFNT font (which helps distinguishing standalone
CFF fonts from CFF in SFNT aka OTF)
Fixes#375
In "Do not return FcFalse from FcConfigParseAndLoad*() if complain is
set to false" [0], _FcConfigParse was updated to return FcTrue early if
it was instructed not to complain on errors. In "Take effect sysroot
functionality to the default config file" [1] the error messages were
factored into a `reason` which was allocated. Be sure to free this
`reason` in the case of returning FcTrue early.
Discovered with a leak checker while attempting to configure in
interesting ways.
[0] fcada52291
[1] cd51cb241a
When building Chromium with upstream Fontconfig with CFI,
the following build error is raised:
../../third_party/fontconfig/src/src/fchash.c:105:21: runtime error:
control flow integrity check for type 'unsigned int (const void *)'
failed during indirect function call
This occurs because CFI doesn't like the conversion from
`unsigned int (const void *)` to `unsigned int (const char *)`.
To fix this, simply redefine `FcHashFunc` to use `char *` instead.
This fixes a regression introduced by 76f88e780. When
using FONTCONFIG_SYSROOT=/home/tom/test_fonts, strace
reveals that fontconfig attempted to open /test_fonts/Ahem.ttf
instead of /home/tom/test_fonts/Ahem.ttf. The fix is to use
`s_dir` instead of `dir` in `file_prefix`.
Getting backtraces against this assertion isn't useful at all.
Fontconfig isn't capable to report who really have a reference
of caches though, this report may be better than assertion.
So we can try analysis tools then.
And report it only when running with FC_DEBUG=16.
LC_CTYPE is set to "UTF-8" on some macOS systems, which is
POSIX-compliant in a strict sense, but breaks the usual assumption
that a locale name has the form "ll_LL.encoding".
https://unix.stackexchange.com/questions/503110/valid-values-for-lc-ctype
Previously, this would cause the warning
Fontconfig warning: ignoring UTF-8: not a valid region tag
Now, we just skip this variable if set to "UTF-8", since that value
doesn't give any language information, and move on to try LANG.
The ctype(3) functions take arguments of type int that are either
(a) EOF, or
(b) unsigned char values, {0, 1, 2, ..., 255} if char is 8-bit.
Passing values of type char, on platforms where it is signed, can go
wrong -- negative values may be confused with EOF (typically -1) or
may lead to undefined behaviour ranging in practice from returning
garbage data (possibly out of an adjacent buffer in memory that may
contain secrets) to crashing with SIGSEGV (if the page preceding the
ctype table is unmapped).
The ctype(3) functions can't themselves convert to unsigned char
because then they would give the wrong answers for EOF, for use with
functions like getchar and fgetc; the user has to cast char to
unsigned char.
Trying to early loading a custom fonts.xml created on the
fly results in the pGetSystemWindowsDirectory function
pointer being found intialized. Normally the initialization
is performed in the default configuration loading.
The commit factorizes the lazy initialization of both
WIN32 getters (together with pSHGetFolderPathA) in a
function and call it when actually needed.
Because the loop body is just 'break' the loop never loops and at most
one leading space is skipped. Remove the body to allow the loop to
continue. Found with ClangTidy.
Instead of fixed number of buckets with chaining use an open addressing
hash table with linear probing, max load factor 0.75, and a power of two
number of buckets.
In particular, if an stdlib header goes first, it includes features.h
which only checks _FILE_OFFSET_BITS *once*, meaning that these files end
up compiled *without* _FILE_OFFSET_BITS taking effect, which affects
fcxml's operations in listing directories.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
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
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.
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
Akira TAGOH
Khaled Hosny
Xavier Claessens
Ben Wagner
msizanoen1
Vitaly Lysenkov
Tom Anderson
Ondrej Balaz
Jean Abou Samra
Taylor R Campbell
Francesco Pretto
Akira TAGOH
Ryan Gonzalez
Behdad Esfahbod
Alex Richardson
Ryan Schmidt
Mehdi Sabwat