1. 03 Apr, 2019 4 commits
    • Akira TAGOH's avatar
      91114d18
    • 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.
      2e8ce635
    • Akira TAGOH's avatar
      Add reset-dirs element · def1d000
      Akira TAGOH authored
      This element removes all of fonts directories where added by
      dir elements. it is useful to override fonts dirs from system
      to their own dirs only.
      def1d000
    • Keith Packard's avatar
      Replace UUID file mechanism with per-directory 'map' attribute [v2] · c4324f54
      Keith Packard authored
      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
      applications.
      
      v2:
      	Leave FcDirCacheCreateUUID stub around to avoid removing
      	public API function.
      
      	Document 'map' attribute of <dir> element in
      	fontconfig-user.sgml
      Suggested-by: Akira TAGOH's avatarAkira TAGOH <akira@tagoh.org>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      c4324f54
  2. 21 Aug, 2018 1 commit
  3. 25 Jul, 2018 1 commit
  4. 16 Jul, 2018 1 commit
    • Tom Anderson's avatar
      Return canonicalized paths from FcConfigRealFilename · d1f48f11
      Tom Anderson authored
      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 7ad010e8.
      
      [1] https://bugs.chromium.org/p/chromium/issues/detail?id=857511
      d1f48f11
  5. 12 Jan, 2016 1 commit
    • Patrick Haller's avatar
      Optimizations in FcStrSet · d570a841
      Patrick Haller authored
      Applied optimizations:
      - skip duplicate check in FcStrSetAppend for values originating from readdir()
      - grow FcStrSet in 64-element bulks for local FcStrSets (FcConfig layout unaltered)
      
      Starting gedit is measured to
      
                              Unoptimized     Optimized
      user[s]                         0,806         0,579
      sys[s]                          0,062         0,062
      Total Instr Fetch Cost: 1.658.683.750   895.069.820
      Cachegrind D Refs:        513.917.619   312.000.436
      Cachegrind Dl Misses:       8.605.632     4.954.639
      d570a841
  6. 27 Jun, 2015 1 commit
    • Behdad Esfahbod's avatar
      Revert changes made to FcConfigAppFontAddDir() recently · 46ec6a52
      Behdad Esfahbod authored
      In 32ac7c75 the behavior of
      FcConfigAppFontAddFile/Dir() were changed to return false
      if not fonts were found.  While this is welldefined and useful
      for AddFile(), it's quite problematic for AddDir().  For example,
      if the directory is empty, is that a failure or success?  Worse,
      the false value from AddDir() was being propagated all the way
      to FcInit() returning false now.  This only happened upon memory
      allocation failure before, and some clients assert that FcInit()
      is successful.
      
      With this change, AddDir() is reverted back to what it was.
      AddFont() change (which was actually in fcdir.c) from the original
      commit is left in.
      46ec6a52
  7. 17 Jun, 2015 1 commit
  8. 24 Jul, 2014 1 commit
  9. 05 Nov, 2013 1 commit
  10. 02 Oct, 2013 1 commit
  11. 08 May, 2013 1 commit
    • Akira TAGOH's avatar
      Use the glob matching for filename · f6244d2c
      Akira TAGOH authored
      Regex is expensive to compare filenames. we already have the glob matching
      and it works enough in this case.
      
      Prior to this change, renaming FcConfigGlobMatch() to FcStrGlobMatch() and moving to fcstr.c
      f6244d2c
  12. 21 Mar, 2013 1 commit
  13. 05 Mar, 2013 1 commit
  14. 08 Jan, 2013 1 commit
    • Behdad Esfahbod's avatar
      Fix memory corruption! · dc21ed28
      Behdad Esfahbod authored
      In FcStrListCreate() we were increasing reference count of set,
      however, if set had a const reference (which is the case for list
      of languages), and with multiple threads, the const ref (-1) was
      getting up to 1 and then a decrease was destroying the set.  Ouch.
      
      Here's the valgrind error, which took me quite a few hours of
      running to catch:
      
      ==4464== Invalid read of size 4
      ==4464==    at 0x4E58FF3: FcStrListNext (fcstr.c:1256)
      ==4464==    by 0x4E3F11D: FcConfigSubstituteWithPat (fccfg.c:1508)
      ==4464==    by 0x4E3F8F4: FcConfigSubstitute (fccfg.c:1729)
      ==4464==    by 0x4009FA: test_match (simple-pthread-test.c:53)
      ==4464==    by 0x400A6E: run_test_in_thread (simple-pthread-test.c:68)
      ==4464==    by 0x507EE99: start_thread (pthread_create.c:308)
      ==4464==  Address 0x6bc0b44 is 4 bytes inside a block of size 24 free'd
      ==4464==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==4464==    by 0x4E58F84: FcStrSetDestroy (fcstr.c:1236)
      ==4464==    by 0x4E3F0C6: FcConfigSubstituteWithPat (fccfg.c:1507)
      ==4464==    by 0x4E3F8F4: FcConfigSubstitute (fccfg.c:1729)
      ==4464==    by 0x4009FA: test_match (simple-pthread-test.c:53)
      ==4464==    by 0x400A6E: run_test_in_thread (simple-pthread-test.c:68)
      ==4464==    by 0x507EE99: start_thread (pthread_create.c:308)
      
      Thread test is running happily now.  Will add the test in a moment.
      dc21ed28
  15. 02 Jan, 2013 4 commits
  16. 30 Dec, 2012 2 commits
  17. 11 Dec, 2012 1 commit
  18. 07 Dec, 2012 1 commit
  19. 09 Oct, 2012 1 commit
  20. 13 Jun, 2012 1 commit
  21. 08 Jun, 2012 1 commit
  22. 01 Jun, 2012 1 commit
  23. 18 May, 2012 1 commit
  24. 20 Apr, 2012 1 commit
  25. 12 Apr, 2012 1 commit
  26. 11 Apr, 2012 1 commit
  27. 21 Feb, 2012 1 commit
  28. 10 Nov, 2010 1 commit
  29. 12 Apr, 2010 1 commit
  30. 24 Jun, 2009 1 commit
  31. 13 Mar, 2009 1 commit
  32. 12 Mar, 2009 2 commits