Re: Fontconfig language update proposal

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


Le 2019-11-28 09:48, Akira TAGOH a écrit :
On Thu, Nov 28, 2019 at 4:07 PM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
You're already doing it for


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

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

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

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.


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