Age | Commit message (Collapse) | Author | Files | Lines |
|
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/
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=106459
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=106497
|
|
Add various APIs to obtain things in FcPattern through the iterator
https://bugs.freedesktop.org/show_bug.cgi?id=43367
|
|
|
|
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 <<".
|
|
Continuation of previous commit.
Makes scanning Voto Serif GX fast again.
|
|
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.
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=105492
|
|
For objects which has been changed the object type to FcTypeRange.
https://bugs.freedesktop.org/show_bug.cgi?id=105415
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=105492
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=105415
|
|
|
|
Patch from Kurt Kartaltepe
|
|
|
|
fallback config
|
|
|
|
|
|
Those elements takes effects immediately during parsing config files so makes them conditional to ignore on scanning.
|
|
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
|
|
|
|
|
|
--its option
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
No idea why I didn't add these as double to begin with.
|
|
|
|
|
|
Ie. flip the merge order.
|
|
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.
|
|
Ouch!
|
|
|
|
When we replace a bucket in the hashtable we have to update the
next pointer too, or we lose all the other elements that hashed to
this key.
|
|
Not proper fix necessarily. But fixes this crash:
https://bugs.freedesktop.org/show_bug.cgi?id=101889#c81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Similar changes to 3a3d6ea applies to fclist and fcmatch.
|
|
|