font-build-system vs fc-cache profile hook

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Arun,
Hi ng0,

On Thu, 11 May 2017 20:15:00 +0000
ng0 <ng0@pragmatique.xyz> wrote:

> I don't think anyone is working on a font-build-system. But this won't
> solve the fc-cache problem as the reply by Mark suggests.

I agree, it won't.

For that, one could merge-install the fonts in a well-known location (that already happens) and then add a profile hook to guix/profiles.scm (%default-profile-hooks).

But there's already a "fonts-dir-file" hook there - which was recently extended to actually traverse all the font dirs and invoke mkfontscale, mkfontdir in them.

So for fixing the font problem it would first require someone to find out what exactly is missing.  What does fc-cache do that mkfontdir and mkfontscale don't?  Is it necessary to invoke all three?  Then we could just invoke all three in the fonts-dir-file hook (or invoke fc-cache in a new hook?).

Note that fc-cache needs to be invoked once per architecture, so it isn't quite as straightforward as it would seem (for example on x86, you'd potentially have to run it once for x86_64 and once for i386 - which means you'd have to find out which architectures are used in the profile).

You can pass a list of "interesting" directories as command-line parameters to fc-cache.

fc-cache supports both user caches and system caches.  You'd have to find out which of those is more appropriate.  Probably the system cache?  So invoke fc-cache "--system-only" ?

Also, can fc-cache handle the Guix timestamp-less directories?  If not, it would have to be invoked with "--force" "--really-force" (the latter makes it unlink existing cache files, the former prevents it from trying to load cache files afterwards).  Would that be slow?

One cache dir is specified when building fontconfig, called FC_CACHEDIR, which can be specified when invoking configure: "--with-cache-dir=DIR" (defaults to LOCALSTATEDIR/cache/fontconfig).  The Guix package for fontconfig overrides it to be /var/cache/fontconfig and I have a lot of files in there (I'm a GuixSD user).

Not sure whether that's good.  Why not put the cache into the profile and have an environment variable point there?  Just using "/var" sounds unsafe for non-GuixSD users... what if the foreign operating system has incompatible files there?  Also, reproducibility?

On the other hand, user cachedirs are in the directory specified by environment variable XDG_CACHE_HOME.

Each cache corresponds to a list of font directories - which are found by appending sysroot and an entry in the cache body.  If sysroot is not set, just the entry in the cache body is used.  I think the former is because the cache filename is a MD5SUM of the font directory name - which can lead to hash collisions.  But later on, FcDirCacheUnlink just unlinks the cache of each directory specified (on really-force, for example) - so if you specify just one of the directories that would cause a collision it will silently invalidate the other one too (which you didn't specify). :P

What are these cache files caching in the first place?  Don't mkfontdir and mkfontscale already cache font family, variant etc?

Also, reading the Arch bugtracker, if not running fc-cache, fontconfig is supposed to generate the cache into the user directory automatically when invoking an application that needs fontconfig fonts.  Not sure how it can happen for them to be broken...

In any case, invoking fc-cache --system-only can't hurt I guess.

But first it would be good to strace some application with broken fonts and see what it's trying to open that fails.