FcFontSetFont() accesses fs->fonts in that macro though, there was no error checks
if it is null or not.
As a result, there was a code path that it could be a null.
Even though this is unlikely to see in usual use, it might be intentionally created
in a cache.
So if fs->fonts is a null, we should consider a cache is invalid.
FcConfigRealFilename() follows symlinks, but the link may be relative to the
directory containing the link. For example, on my system, I have this file:
/etc/fonts/conf.d/99-language-selector-zh.conf ->
../conf.avail/99-language-selector-zh.conf
Since /etc/fonts/conf.d is probably not in PATH, open()ing the file would fail.
This change makes FcConfigRealFilename() return the canonicalized filename
instead. So for the example above, it would return:
/etc/fonts/conf.avail/99-language-selector-zh.conf
This was causing bad font rendering in Chromium [1] after the regression I
introduced in 7ad010e80b.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=857511
CFI [1] is a dynamic analysis tool that checks types at runtime. It reports an
error when using a function with signature eg. (void (*)(char*)) as
(void (*)(void*)). This change adds some wrapper functions to avoid this issue.
In optimized builds, the functions should get optimized away.
[1] https://clang.llvm.org/docs/ControlFlowIntegrity.html
This changes the rewriting of the FC_FILE values for relocated caches to an earlier stage
while reading the cache. This is better, because it means all APIs will report the
rewritten paths, not just the once that use the list apis.
We do this by detecting the relocated case and duplicating the FcPattern and FcPatternElm
in an cache allocation (which will die with the cache) and then reusing the FcValueLists
from the cache.
This means that in the rewritten case we will use some more memory, but not the full
size of the cache. In a test here I had 800k of relocated caches, but ~200k of wasted
on duplicating the objects.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=106618
Whilst working on the Reproducible Builds[0] effort, we noticed that
fontconfig generates unreproducible cache files.
This is due to fc-cache uses the modification timestamps of each
directory in the "checksum" and "checksum_nano" members of the _FcCache
struct. This is so that it can identify which cache files are valid
and/or require regeneration.
This patch changes the behaviour of the checksum calculations to prefer
the value of the SOURCE_DATE_EPOCH[1] environment variable over the
directory's own mtime. This variable can then be exported by build
systems to ensure reproducible output.
If SOURCE_DATE_EPOCH is not set or is newer than the mtime of the
directory, the existing behaviour is unchanged.
This work was sponsored by Tails[2].
[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://tails.boum.org/
realfilename is the file name after sysroot adjustments. It should be used
instead of filename in the call to FcOpen() which forwards the name directly to
open().
Though I don't explicitly request a sysroot, I was getting error messages saying
"failed reading config file". This CL fixes the error spam.
The expression "1 << 31" will cause UBSAN to complain with this error message:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
The same operation on unsigned types is fine, however. This CL replaces the
strings "1 <<" with "1U <<".
In 161c738 I switched from linear name scanning to binary searching.
That, however, ignored the fact that there might be more than one
name table entry for each pair we want to query.
To fix that and retain bsearch, I now get all name entries first,
sort them, and use for bsearching.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=105756
This makes scaning Voto Serif GX twice slower though, since we are
creating and sorting the list for each instance. In the next commit,
I'll share this list across different instances to fix this.
We were comparing the passed in key with the ready-to-insert key
rather than the key in the hashtable, so if you ever had a hash
conflicts we'll never insert the new item.
https://bugs.freedesktop.org/show_bug.cgi?id=101889
Fontconfig symbols were hardcoded to be either hidden or exported. This patch
adds configurable symbol visibility. This is useful for projects that want to
do in-tree fontconfig builds and not export any symbols, otherwise they would
conflict with the system library's symbols
Chromium is a project that does in-tree fontconfig builds, and the workaround
currently used is "#define visibility(x) // nothing" [1] and building with
"-fvisibility=hidden".
[1] https://cs.chromium.org/chromium/src/third_party/fontconfig/BUILD.gn?rcl=ce146f1f300988c960e1eecf8a61b238d6fd7f7f&l=62
This is the last piece of the puzzle for variable-font support in
fontconfig. This takes care of automatically setting the variation
settings when user requests a weight / width / size that has variation
in the matched font.
When a cache contains no fonts, it will be unloaded immediately.
Previously the certain alias and UUID entries will be purged at that time though,
this doesn't work when the targeted directory has sub-directories.
To avoid the unnecessary cache creation with the md5-based naming, try to keep them
as far as possible.
Although this way seems not perfectly working if the first directory to look up is like that
Reject caches when FcPattern isn't a constant.
This is usually unlikely to happen but reported.
I've decided to add more validation since this isn't reproducible
and easy to have a workaround rather than investigating 'why'.
https://bugs.freedesktop.org/show_bug.cgi?id=103237
Trying to address what these configuration files really do.
This change allows to see the short description that mention
the purpose of the content in the config file and obtain
them through API.
This change also encourage one who want to make some UI for
the user-specific configuration management. it is the main
purpose of this change for me though.
Aside from that, I've also made programs translatable. so
we see more dependencies on the build time for gettext,
and itstool to generate PO from xml.
VotoSerifGX has over 500 named instances, which means it also has over a thousand
name table entries. So we were looking for names for over 500 pattern, looking for
some thirty different name-ids, and using linear search across the 1000 entries!
Makes scanning VotoSerifGX three times faster. The rest is probably the lang
matching, which can also be shared across named-instances. Upcoming.
Akira TAGOH
Tom Anderson
Behdad Esfahbod
Matthieu Herrb
Alexander Larsson
Chris Lamb
Olivier Crête
Alexander Kanavin