font-build-system vs fc-cache profile hook

[Danny Milosavljevic]

Hi Arun,
Hi ng0,

On Thu, 11 May 2017 20:15:00 +0000
ng0 <address@hidden> 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.