font-build-system

font-build-system

[ng0]

Hi,

we have 20 - 25 fonts (I didn't really count), and only 2 are using a

system* make args

in their build phase, every other font just extracts, creates folders
and copies the fonts to the folders.
This is much repetition which could be avoided by just calling a build
system, rather than applying changes to fonts over and over again.

It looks like this can be achieved by something as small as the emacs
build-system. Would anyone give it a try?
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: font-build-system

[Ludovic Courtès]

ng0 <contact.ng0@cryptolab.net> skribis:

> we have 20 - 25 fonts (I didn't really count), and only 2 are using a
>
> system* make args
>
> in their build phase, every other font just extracts, creates folders
> and copies the fonts to the folders.
> This is much repetition which could be avoided by just calling a build
> system, rather than applying changes to fonts over and over again.
>
> It looks like this can be achieved by something as small as the emacs
> build-system. Would anyone give it a try?

That’s a good idea.  It might be that there are subtle differences among
the font packages, though.

Ludo’.

Re: font-build-system

[Arun Isaac]

ng0 writes:

> we have 20 - 25 fonts (I didn't really count), and only 2 are using a
>
> system* make args
>
> in their build phase, every other font just extracts, creates folders
> and copies the fonts to the folders.
> This is much repetition which could be avoided by just calling a build
> system, rather than applying changes to fonts over and over again.
>
> It looks like this can be achieved by something as small as the emacs
> build-system. Would anyone give it a try?

Is anybody working on this? I'd like to give this a shot, if nobody else
is working on it already.

Re: font-build-system

[ng0]

Arun Isaac transcribed 0.6K bytes:
> 
> ng0 writes:
> 
> > we have 20 - 25 fonts (I didn't really count), and only 2 are using a
> >
> > system* make args
> >
> > in their build phase, every other font just extracts, creates folders
> > and copies the fonts to the folders.
> > This is much repetition which could be avoided by just calling a build
> > system, rather than applying changes to fonts over and over again.
> >
> > It looks like this can be achieved by something as small as the emacs
> > build-system. Would anyone give it a try?
> 
> Is anybody working on this? I'd like to give this a shot, if nobody else
> is working on it already.
> 

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.

A build system would be good though.
-- 
https://pragmatique.xyz
PGP: https://people.pragmatique.xyz/ng0/

font-build-system vs fc-cache profile hook

[Danny Milosavljevic]

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.

Re: font-build-system

[Arun Isaac]

> But this won't solve the fc-cache problem as the reply by Mark
> suggests.
>
> A build system would be good though.

I didn't mean to solve the fc-cache problem. I was only talking about
the unpack and install phases which was the original subject of this
thread. We can add the fc-cache part of the solution later, once we have
figured it out.

Re: font-build-system

[Arun Isaac]

>> But this won't solve the fc-cache problem as the reply by Mark
>> suggests.
>>
>> A build system would be good though.
>
> I didn't mean to solve the fc-cache problem. I was only talking about
> the unpack and install phases which was the original subject of this
> thread. We can add the fc-cache part of the solution later, once we have
> figured it out.

I have WIP patches for a font-build-system here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26941