[Top][All Lists]

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

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

From: Andrew Patterson
Subject: [bug#62806] [PATCH] gnu: home: services: fontutils: Add support for SXML fragments.
Date: Mon, 24 Apr 2023 19:24:31 -0400
User-agent: mu4e 1.10.2; emacs 30.0.50

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

Nice! You’re the third person looking into this, which shows there’s a
real need.  :-)

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

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.


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

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

Andrew Patterson

reply via email to

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