[bug#57963] [PATCH 1/1] home: fontutils: Support user's fontconfig.

[Taiju HIGASHI]

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

> Am Mittwoch, dem 21.09.2022 um 18:59 +0900 schrieb Taiju HIGASHI:
>> Hi Liliana,
>>
>> Thank you for your review.
>>
>> > > -(define (add-fontconfig-config-file he-symlink-path)
>> > > +(define (add-fontconfig-config-file font-config)
>> > >    `(("fontconfig/fonts.conf"
>> > >       ,(mixed-text-file
>> > >         "fonts.conf"
>> > >         "<?xml version='1.0'?>
>> > >  <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
>> > >  <fontconfig>
>> > > -  <dir>~/.guix-home/profile/share/fonts</dir>
>> > > -</fontconfig>"))))
>> > > +  <dir>~/.guix-home/profile/share/fonts</dir>\n"
>> > > +       (if (null? font-config)
>> > > +           ""
>> > > +           (string-join font-config "\n" 'suffix))
>> > > +       "</fontconfig>\n"))))
>> > I think it'd be wiser to pretty-print SXML here.
>> > The structure could look something like
>> > `(fontconfig
>> >    (dir "~/.guix-home/profile/share/fonts")
>> >    ,@(extra-user-config ...))
>>
>> That's definitely better!
>> Does this assume that SXML will also accept additional user settings?
> It assumes that whatever (extra-user-config ...) does, it returns a
> list of SXML nodes, e.g. ((dir "~/.fonts")).  Writing correct SXML
> should be comparatively simpler to writing correct XML.

I just sent you the v2 patch.  It uses SXML to handle the user's extra
configs.
I also made it so that the user can pass SXML directly.

I also wrote a test but did not include it in the patch because I
thought it would be a technical debt.
I'm attaching that as a reference.

fontutils.scm
Description: tests/home-services/fontutils.scm

>> > Also, for the particular use case of handling multiple profiles
>> > gracefully (rather than the current status quo) I think fontconfig-
>> > service-type should be able to construct (dir
>> > "#$profile/share/fonts") style entries on its own.  However, given
>> > that multiple profiles aren't supported yet, this is future work.
>>
>> Noted. I believe that even with the current patch, it is possible to
>> add arbitrary directories, so it will be better than what we have
>> now.
> That's fine, just know that this use case might at some point become
> obsolete thanks to a better implementation :)

No problem. I would like to solve the current problem first. A better
implementation is always welcome :)

Cheers
-- 
taiju