[bug#62806] [PATCH] gnu: home: services: fontutils: Add support for SXML fragments.

[Andrew Patterson]

On Mon, 2023-04-24 at 22:41+02, Ludovic Courtès <ludo@gnu.org> 
wrote:

> Nice!  You’re the third person looking into this, which shows 
> there’s a
> real need.  :-)
>
>   https://issues.guix.gnu.org/62145
>   https://issues.guix.gnu.org/57963
>
> I like that your patch is simple (it doesn’t try to do anything 
> beyond
> serializing SXML); perhaps there are ideas to borrow from the 
> patch by
> Taiju HIGASHI?
>
> OTOH it’s less convenient to use for someone who’s not familiar 
> with the
> XML schema of ‘fonts.conf’ than what the patch by conses does.
>
> I think we should really move forward on this.  Because it’s not
> invasive, this patch sounds like the path of least resistance.

Thanks!

> What are your thoughts, people?  What should we choose?  :-)

Brain dump below:

My patch was an attempt to do the least work to get fontconfig
configuration working, so I agree on it being the simplest option.
(As I would, being it's author.)
Whatever we end up with shouldn't break existing configurations, 
of
course, and should have /some/ way to add arbitrary XML 
configuration,
preferably as SXML.

Both general principles and the other patches suggest we should
have an actual configuration record, though, with slots for
default font families, additional font directories, and extra SXML
config.  IMHO, the main design question for this is whether the
default font family slots should be single font family names,
leaving setting up default fonts with fallback fonts as a complex
case written in SXML, or should be a list of font families.
The list of font families is more annoying for the common case, 
but
my fonts.conf does have fallback defaults, so it is useful.

home-fontconfig-service-type probably should be taken out of
%base-home-services, as Taiju HAGASHI's patch eventually did, but
that scope creep looks like it was part of why the patch went
nowhere.

I like the idea of conses' <font-spec> record, but it seems like
it'd be awkward in practice?  An example config might help.

My write-fontconfig-doctype hack was definitely a bad idea: 
calling
thunks in the SXML with the output port as current-output-port
doesn't seem to be a purposeful feature, and just writing the
doctype tag separately is more clear.

It seems to me that the main options are:
1) Just use my patch, or
2) write a new patch with an actual configuration record type,
  based on conses and Taiju HAGASHI's patches, either with
  a) a single font family for the default font family settings,
  b) a list of font families for the default font families, or
  c) allowing either.

If we don't want to just use my patch, I can work on a new patch
with a configuration record.  How do you print a deprecation
warning?

--
Andrew Patterson