guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Liliana Marie Prikler
Subject: [bug#57963] [PATCH 1/1] home: fontutils: Support user's fontconfig.
Date: Wed, 21 Sep 2022 13:40:14 +0200
User-agent: Evolution 3.45.3

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.

> > 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 :)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]