Le 2019-11-28 12:19, Akira TAGOH a écrit :

On Thu, Nov 28, 2019 at 6:36 PM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:

...

Le 2019-11-28 09:48, Akira TAGOH a écrit :

...

On Thu, Nov 28, 2019 at 4:07 PM Nicolas Mailhot nicolas.mailhot@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).

Well, it *is*, at least at this moment. and you are misunderstanding on it. we don't have any agreements on how fontvariations property can be parameterized in configuration yet.

Ok, I misunderstood, sorry. The examples in the proposal show the same need as the requester at the config level (human setting not library setting).

...

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.

I see, but I'm wondering if it is really possible,

It is really possible. Font creators make the same mistakes in all font projects and they can all be fixed the same way. In that sense modern complex fonts projects are really not interesting: they contain the same mistakes that 20 years old projects. Except that now there is a lot more font files to make mistakes in, we have more font files to fix.

particularly doubt as long as we have something in configuration. we could reduce the amount of *characters* in a file to modify perhaps but always need to check if it is valid or not when font vendors/authors has a new release.

Human time is limited. Sure, checking the result does not go away. Not having to comb thousands of conf lines for synbax or declaration problems frees up time to actually check the result.

...

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

I'm sorry, I missed your point again. If I'm not missing the discussion here, we were talking about locale-specific recipe in configuration, particularly my proposal to drop unexpected language coverage from caches instead of checking the desired language at runtime, right? There are no prioritization rules there.

Lang block selection interacts with prioritization both at the font family and at the generic level. It's inherently a prioritization problem.

Well, I meant to be "generic syntax vs dedicated syntax". as a contrast, "simple and dedicated syntax" is what you want, no? syntax sugars are dedicated though.

I want simple syntax to handle generic problems. It's not “dedicated” syntax. The same problems occur again and again in most font projects regardless of their foundry.

Regards,