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
<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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
