[bug#57963] [PATCH 0/1] Support user's fontconfig.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Sonntag, dem 25.09.2022 um 16:29 +0900 schrieb Taiju HIGASHI:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Sonntag, dem 25.09.2022 um 07:58 +0900 schrieb Taiju HIGASHI:
> > > Ludovic Courtès <ludo@gnu.org> writes:
> > > 
> > > > Anyway, it does look like your v2 is the way to go, with the
> > > > obvious caveat that using it is tricky: one needs to know about
> > > > fontconfig’s config file format and about sxml.
> > > > 
> > > > Maybe we can go with v2 for now (it provides a useful “escape
> > > > hatch”) but prepare for more conventional configuration
> > > > bindings?
> > > 
> > > By conventional configuration binding, do you mean adding
> > > something
> > > like home-fontconfig-configuration to provide a dedicated 
> > > fontconfig
> > > configuration?
> > I think Ludo means that we should provide the most useful options
> > (like the fontconfig dirs) as dedicated record fields, while
> > leaving an "extra-config" escape hatch, that can be used with SXML
> > or a raw string for stuff that's too complicated (my personal
> > preference would still be SXML over the raw string, but YMMV).
> 
> I see.  For example,
> 
> For example, would it be as follows?
> 
> --8<---------------cut here---------------start------------->8---
> (service home-fontconfig-service-type
>   (home-fontconfig-configuration
>     (dir "~/.config/fontconfig/my-fonts1.conf"))
>   (extra-config
>     (list
>       "<dir>~/.config/fontconfig/my-fonts2.conf")))
> --8<---------------cut here---------------end--------------->8---
Since you can specify more than one dir, that'd be "dirs" or even
something more helpful like "font-directories".  Note that those are
directories and not config files.

You corrected the extra-config thing in your reply, but also be aware
of the extra-config as SXML option.

> 
> > > I have been reading the DTD and think it might be a bit of a
> > > challenge.
> > > https://github.com/freedesktop/fontconfig/blob/e291fda7d42e5d64379555097a066d9c2c4efce3/fonts.dtd
> > > 
> > > However, I did notice one thing, and that is that there is an
> > > include element.  I thought that if we had a configuration where
> > > the include element could be added, we could handle most of the
> > > use cases.  What do you think of this idea?
> > I'd prefer extra-config over include – extra-config doesn't need to
> > go through file-like objects and an additional layer of G-
> > Expression quoting.
> > 
> > Cheers
> 
> It is difficult to determine which rules to define as records, but I
> thought that if I only had includes, I could handle most use cases.
Go for the obvious low-hanging fruits and typical use cases first. 
Don't just add a field that requires a depth of 3 or more to be useful.

> For example, we assume that you will be able to write settings as
> follows:
> 
> --8<---------------cut here---------------start------------->8---
> (service home-fontconfig-service-type
>   (home-fontconfig-configuration
>     (includes
>       (list
>         (include
>           (path "~/.config/fontconfig/my-fonts1.conf")
>           (ignore-missing #t))))))
> --8<---------------cut here---------------end--------------->8---
> 
> ref:
> https://github.com/freedesktop/fontconfig/blob/e291fda7d42e5d64379555097a066d9c2c4efce3/fonts.dtd#L59-L74
> 
> Would it also fit with your assumption if we could also specify
> extra-config here?
> 
> It is difficult to judge whether the ability to specify includes is
> useful or not, though, since extra-config alone will do the job.
Except for possibly some fringe use cases, include will be pointless if
you have extra-config, which is a better include :)

Cheers