Re: Fontconfig language update proposal

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


Le 2019-11-26 10:47, Akira TAGOH a écrit :

Hi Akira,

Ideally fonts would be available in fontconfig with minimal effort,
and writing a configuration file to make up for missing pieces. we may
need to figure out if we really can't implement it as a core feature
of fontconfig and have to leave it to the users, to let them write a

On the long term, fontconfig should automate all the guesswork heuristics that humans use to make sense of the pile of approximative metadata foundries release. There’s no reason the heuristics will work worse when automated than when done as a manual process.

This proposal is a lot more modest. It's just streamlining the current dumb fontconfig mode, where users provide the information needed by the engine, without any engine smarts.

Once this streamlining is finished it will be much clearer, where fontconfig needs human help, and where more smarts is needed engine-side.

On Sun, Nov 24, 2019 at 4:30 AM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
It is presented both in traditional XML, and in YAML.

I'm not keen on writing a configuration in YAML. particularly I don't
think current features in XML can be represented in YAML to write some
procedures and expressions.

Raw XML is very poor to express lists and dicts of things natively. And the new large-encoding font projects need those lists and dict in the config (for example, good lang lists, or variable axis step declarations).

I suppose it would be possible to define some XML elements, that contain a yaml list or dict in the text node. I don't like this kind of mixed syntax much, but that’s the only way I see to keep something XML-ish that scales humanly to the kind of list/dict we will need.


The proposal avoids over-specifying low-level fontconfig behaviour,
leaving room to tweak the logic when new lessons are learnt, without
requiring the rewrite of thousands of configuration lines spread over
hundreds of files.

To be sure, about the line of "without requiring the rewrite of...",
which one particularly were you talking about? and which one in your
proposal will improve that?

Pretty much all its parts.

The proposal specifies font elements to group, with their associated characteristics (good/bad lang, broken styles, etc). What fontconfig does with this info can change over time.

That‘s a departure from the current level of abstraction, where humans directly set all the engine low-level actions. The current state has the following consequences:

1. it’s not possible to reconstruct reliably, the intent behind a configuration. That means, a CI/CD system can not deduce, the objective, behind a config file (and therefore, check it is attained)

2. whenever hindsight shows the low-level sequence needed to achieve a generic goal needs tweaking, the whole configuration needs rewriting, instead of just adjusting things at the engine level.


Nicolas Mailhot
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux