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@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.
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
_______________________________________________
fonts mailing list -- fonts@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to fonts-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/fonts@xxxxxxxxxxxxxxxxxxxxxxx
