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.