[Fontconfig] Fontconfig language update proposal

[Nicolas Mailhot]

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

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 at laposte.net> 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.

>> CORRECT ABSTRACTION LEVEL
>> 
>> 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.

Regards,

-- 
Nicolas Mailhot