[Fontconfig] Fontconfig language update proposal

[Nicolas Mailhot]

Le 2019-11-28 09:48, Akira TAGOH a écrit :
> On Thu, Nov 28, 2019 at 4:07 PM Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
>> You're already doing it for
>> 
>> <fontvariations>AXIS1=VALUE;AXIS2=VALUE</fontvariations>
>> 
>> Except it's neither an XML nor a YAML list, it’s a one-of-a-kind dict
>> format that can not be parsed natively by any off-the-shelf XML or 
>> YAML
>> parser.
> 
> That is just a string *in* fontconfig.

It’s not just a string *in* fontconfig. It affects styles. style 
manipulation is part of fontconfig rules. Except that here it relies on 
an un-parsable dict (without specific code).

>> That's 100% due to a bad abstraction level in fontconfig, where 
>> instead
>> of telling the engine what locale a font file is good for (letting the
>> engine compute the appropriate priorization strategy), users have to
>> hardcode a specific handling strategy in their config files.
> 
> Hmm, I'm still not clear what you are trying...  in that sense, what
> you are proposing would also introduce rewriting.

I would leave the exact rewriting strategy to the engine, so a single 
*uniform* rewriting strategy was applied to all fonts on the system, and 
every font packager need not specify all of the nitty gritty details by 
hand every time there is a new font file to add, and need no check that 
other font files were processed with the same nitty gritty details.

Rewriting is forced on us by the way foundries release font files. We’ve 
waited two decades for foundries to apply the OpenType naming 
recommendations that would make a lot of rewriting unnecessary. Well, 
foundries didn't and won't apply those consistently. So rewriting needs 
to happen fontconfig side.

Without rewriting font substitution does not work, even within a single 
upstream font project, because of small discrepancies in upstream font 
files.

> it may be "only
> once", but the above changes you referenced may be "only once" as
> well.

It’s not remotely the same thing. The alternatives you talk about 
require changing and maintaining thousands of low-level instructions in 
config files. Those low-level instructions interact with thousands of 
other low-level instructions with complex prioritization rules (not 
prioritization rules handled engine side, prioritization rules that 
happen as a side-effect of the ordering of the low-level instructions).

The result is an house of cards. It is not viable long term. Next time 
the OpenType spec adds some twists, or experience shows the low-level 
stuff needs tweaking, those thousands of instructions will need changing 
accordingly.

My proposal shrinks the configuration to the bare minimum human info 
fontconfig does not autodetect today. It can only shrink further, as 
fontconfig gets smarter. It does not suffer from all the low-level 
prioritization interactions crap, because the config files posit a 
common handling strategy engine-side, instead of considering that every 
single font file on system needs a different management strategy (which 
is completely insane, current fontconfig syntax makes exceptions the 
general case, instead of keeping them as exceptions).

You need to evaluate fontconfig syntax a the system level, not the 
individual instruction level. The low-level instructions work in 
isolation. They do not work as a whole. You're asking fontconfig users 
to write things in fontconfig bytecode language, instead of writing 
things at the level humans expect.

And I write this as someone, who invested years understanding the 
fontconfig bytecode. I am *not* a normal user. Normal users are even 
*less* likely to learn and use this low-level stuff than me.

That wouldn't matter, if foundries released quality font files, that 
didn’t need fixing. They do not. It's time to accept reality and move 
on.

> Again, there shouldn't be that difference between them. that would be
> "complicated vs simple" or "generic vs dedicated". both have pros and
> cons.

Stop here. generic is the only way forward.

The average free desktop systems uses hundreds if not thousands of font 
files. It's been a *very* long time since a free desktop was limited to 
the same handful of xorg font files.

Do you want me to count the number of font files in Plex alone? In 
Droid? In Fira? In Noto?

You need to go generic or give up on fontconfig as the system font 
manager.

There are no magical fairies out there that will decline a generic 
strategy for all the font files installed on free desktop systems, using 
the hundreds of configuration lines the current syntax requires.

Regards,

-- 
Nicolas Mailhot