guix-patches
[Top][All Lists]
Advanced

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

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


From: Taiju HIGASHI
Subject: [bug#57963] [PATCH 0/1] Support user's fontconfig.
Date: Sun, 25 Sep 2022 16:29:51 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

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

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





reply via email to

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