GNU bug report logs - #57963
[PATCH 0/1] Support user's fontconfig.

Previous Next

Package: guix-patches;

Reported by: Taiju HIGASHI <higashi <at> taiju.info>

Date: Wed, 21 Sep 2022 00:28:02 UTC

Severity: normal

Tags: patch

Full log


Message #47 received at 57963 <at> debbugs.gnu.org (full text, mbox):

From: Taiju HIGASHI <higashi <at> taiju.info>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 57963 <at> debbugs.gnu.org,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: bug#57963: [PATCH 0/1] Support user's fontconfig.
Date: Sun, 25 Sep 2022 16:29:51 +0900
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Sonntag, dem 25.09.2022 um 07:58 +0900 schrieb Taiju HIGASHI:
>> Ludovic Courtès <ludo <at> 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---

>> 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.

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.

Thanks,
-- 
Taiju




This bug report was last modified 215 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.