1. 01 Jul, 2020 1 commit
  2. 12 May, 2020 1 commit
    • Akira TAGOH's avatar
      Fix cache conflicts on OSTree based system · fdbd9d13
      Akira TAGOH authored
      mtime isn't reliable to detect updates of fonts on OSTree based system
      since they reset mtime to 0 for system files.
      Due to this, there are the situation likely to happen where mtime is
      newer but content is older.
      Fortunately, OSTree based system requires reboot to deploy changes. so
      we can assume we won't see any changes on system fonts. so system caches
      are always up-to-date. we can ignore meta data for system fonts in
      user caches.
  3. 23 Mar, 2020 1 commit
    • Akira TAGOH's avatar
      Fix assertion in FcCacheFini() again · 6f6b3978
      Akira TAGOH authored
      The previous fix in fbc05949 was wrong. reverting.
      When reading older caches, FcDirCacheMapHelper() returns FcFalse and
      it became the return value from FcDirCacheProcess() too, which is wrong.
      Actually one of calls for FcDirCacheMapHelper() should be successfully
      finished and closure should have a valid pointer for cache.
      Due to this, the proper finalization process wasn't running against
      cache in closure.
      Fixes #227
  4. 26 Feb, 2020 1 commit
    • Akira TAGOH's avatar
      Fix assertion in FcFini() · fbc05949
      Akira TAGOH authored
      Due to the unproper initialization of `latest_mtime', the duplicate caches
      was still in fcCacheChains with no references. which means no one frees
      them. thus, the memory leak was happened.
      Fixes #227
  5. 06 Nov, 2019 1 commit
  6. 01 Nov, 2019 1 commit
  7. 31 Oct, 2019 1 commit
  8. 28 Oct, 2019 1 commit
    • Akira TAGOH's avatar
      Read latest cache in paths · c9862b6e
      Akira TAGOH authored
      Right now fontconfig uses a cache found first in a path and
      cachedirs are the order of the system-wide path and then the user path.
      this is due to avoid writing caches into the user path when running as root.
      However, changing caches by certain config only, e.g. using <match target="scan">
      may not take effect by this behavior, because it may be stored into the user path.
      Thus, needing to find the latest cache out from paths.
      Fixes #182
  9. 23 Jul, 2019 1 commit
  10. 10 Jun, 2019 1 commit
  11. 04 Apr, 2019 2 commits
  12. 03 Apr, 2019 6 commits
    • Akira TAGOH's avatar
      Oops, Terminate string · d1acc73f
      Akira TAGOH authored
    • Akira TAGOH's avatar
      Add some debugging output · fc9f706e
      Akira TAGOH authored
    • Akira TAGOH's avatar
      Add salt attribute to dir and remap-dir elements · 2e8ce635
      Akira TAGOH authored
      'salt' attribute affects a cache filename to generate different name from directory name.
      This is useful when sharing caches with host on sandbox and/or give a filename differently:
          <dir salt="randomdata">/usr/share/fonts</dir>
          <remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir>
      Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host.
      and write a cache for their own fonts on /usr/share/fonts with different name.
    • Akira TAGOH's avatar
      Drop a line to include uuid.h · 500e77a0
      Akira TAGOH authored
    • Keith Packard's avatar
      Replace UUID file mechanism with per-directory 'map' attribute [v2] · c4324f54
      Keith Packard authored and Akira TAGOH's avatar Akira TAGOH committed
      The UUID files would be placed in each font directory to provide the
      unique cache name, independent of path, for that directory. The UUID
      files are undesireable for a couple of reasons:
       1) They must be placed in the font directories to be useful. This
          requires modifying the font directories themselves, introducing
          potential visible timestamp changes when running multiple
          applications, and makes the cache processing inconsistent between
          applications with permission to write to the font directories and
          applications without such permission.
       2) The UUID contents were generated randomly, which makes the font
          cache not reproducible across multiple runs.
      One proposed fix for 2) is to make the UUID dependent on the font
      directory path, but once we do that, we can simply use the font
      directory path itself as the key as the original MD5-based font cache
      naming mechanism did.
      The goal of the UUID file mechanism was to fix startup time of
      flatpaks; as the font path names inside the flatpak did not match the
      font path names in the base system, the font cache would need to be
      reconstructed the first time the flatpak was launched.
      The new mechanism for doing this is to allow each '<dir>' element in
      the configuration include a 'map' attribute. When looking for a cache
      file for a particular directory, if the directory name starts with the
      contents of the <dir> element, that portion of the name will be
      replaced with the value of the 'map' attribute.
      Outside of the flatpak, nothing need change -- fontconfig will build
      cache files using real directory names.
      Inside the flatpak, the custom fonts.conf file will now include
      mappings such as this:
      	<dir map="/usr/share/fonts">/run/host/fonts</dir>
      When scanning the directory /run/host/fonts/ttf, fontconfig will
      use the name /usr/share/fonts/ttf as the source for building the cache
      file name.
      The existing FC_FILE replacement code used for the UUID-based
      implementation continues to correctly adapt font path names seen by
      	Leave FcDirCacheCreateUUID stub around to avoid removing
      	public API function.
      	Document 'map' attribute of <dir> element in
      Suggested-by: Akira TAGOH's avatarAkira TAGOH <akira@tagoh.org>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
    • Akira TAGOH's avatar
      Reset errno to do error handling properly · 97fa77d2
      Akira TAGOH authored
      This fixes the weird behavior when running with SOURCE_DATE_EPOCH=0:
      Fontconfig: SOURCE_DATE_EPOCH: strtoull: No such file or directory: 0
  13. 22 Mar, 2019 1 commit
  14. 25 Jan, 2019 1 commit
  15. 30 Nov, 2018 1 commit
    • Akira TAGOH's avatar
      Fix a dereference of a null pointer · b047e299
      Akira TAGOH authored
      When exiting from for loop by not satisfying the condition of `(s = next[i])` at FcCacheRemoveUnlocked()
      referring s->alloated will be invalid.
  16. 05 Oct, 2018 2 commits
  17. 19 Jul, 2018 4 commits
  18. 10 Jul, 2018 1 commit
  19. 13 Jun, 2018 1 commit
  20. 11 Jun, 2018 1 commit
  21. 25 May, 2018 2 commits
  22. 16 May, 2018 1 commit
    • Chris Lamb's avatar
      Ensure cache checksums are deterministic · f098adac
      Chris Lamb authored and Akira TAGOH's avatar Akira TAGOH committed
      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/
  23. 13 May, 2018 1 commit
  24. 18 Dec, 2017 3 commits
  25. 20 Nov, 2017 3 commits