Package: fontconfig
Version: 2.6.0-1
Severity: wishlist

So I just installed a bunch of fonts and BOY IS IT SLOW.

There are two things going on.

(1) "Updating fontconfig cache for /usr/share/fonts/..."
(2) "Regenerating fonts cache"
#2 is done independently by a very large number of font packages calling

HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1

#1 is done by a large number of packages calling 

defoma-font --reregister-all /etc/defoma/hints/XXX.hints

which ends up calling /usr/share/defoma/scripts/fontconfig.defoma, which
calls 

fc-cache -f
and
fc-cache -s *TWICE*.

So fc-cache can be run four or more times *per font installation*.  And 
it actually needs to be run precisely once per apt-get run.

The obvious way to fix this is dpkg triggers.  fontconfig should have a 
trigger on any change to /usr/share/fonts which causes it to regenerate
the cache.  fontconfig.triggers would look like this:

interest /usr/share/fonts

And fontconfig.postinst would be patched like this:
--- fontconfig.postinst 2008-09-14 12:52:55.000000000 -0400
+++ fontconfig.postinst.new     2008-09-14 12:54:27.000000000 -0400
@@ -37,6 +37,8 @@
   done
   printf "done.\n"
   fi
+fi
+if [ "$1" = "configure" ] || [ "$1" = "triggered" ]
   # Force regeneration of all fontconfig cache files.
   mkdir -p /var/cache/fontconfig
   printf "Regenerating fonts cache... "

This would allow bugs to be filed on all packages (except fontconfig and 
defoma) which run fc-cache in postinst, to just remove those explicit 
invocations.  That would speed things up quite a bit.  This should be 
done *now*.

---

The interaction with defoma is much trickier and a much larger problem.  
First of all, defoma *could* be invoked on a nonstandard directory,
which would require a hand run of fc-cache.  It could also be invoked by 
hand for locally installed fonts in /usr/local or the user's home 
directory.

Second, the current fontconfig.defoma script does something very ugly in 
its 'term' subroutine.  It runs fc-cache, then blows away 
/var/lib/defoma/fontconfig.d/fonts.conf, then runs fc-list to determine 
the accessible font directories "without" defoma, then rebuilds 
/var/lib/defoma/fontconfig.d/fonts.conf, then runs fc-cache AGAIN.

This is hideous and very, very slow.  I don't see any way to avoid this 
when using locally installed fonts, for which it is pretty much doing 
the right thing.  There's got to be some way to bypass this for packaged 
fonts, however.  I figure we can simply detect whether we're dealing 
with a subdirectory of /usr/share/fonts, and assume that we're in a 
'packaged' situation then, and if not, assume that we're not.  I almost 
finished a patch to do exactly this, but I hit a problem.

The problem is that the rebuilding of 
/var/lib/defoma/fontconfig.d/fonts.conf *both* rebuilds the directory 
list (which we can just skip for fonts in the standard directories under 
/usr/share/fonts), *and* the aliases and substitutes lists (which I 
believe we *can't* skip -- if we can skip them, tell me and I'll attach 
the patch for fontconfig.defoma).  I'm not currently seeing how to 
preserve the directory list while rebuilding the aliases and substitutes 
lists.

If you could break the file into two pieces, one for the directories and 
one for the aliases and substitutions, it would be quite straightforward 
to rewrite fontconfig.defoma to skip all the tedious cache rebuilds when 
it's dealing with a font in /usr/share/fonts.  (All such fonts should be 
handled by dpkg, and therefore we can rely on the trigger to rebuild the 
cache.)

-- Nathanael Nerode (neroden at gcc dot gnu dot org)

Versions of packages fontconfig depends on:
ii  fontconfig-config             2.6.0-1    generic font configuration library
ii  libc6                         2.7-13     GNU C Library: Shared libraries
ii  libfontconfig1                2.6.0-1    generic font configuration library

fontconfig recommends no packages.

Versions of packages fontconfig suggests:
ii  defoma                       0.11.10-0.2 Debian Font Manager -- automatic f

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to