[Fontconfig] Fontconfig language update proposal

[Nicolas Mailhot]

Le 2019-11-28 12:19, Akira TAGOH a écrit :
> On Thu, Nov 28, 2019 at 6:36 PM Nicolas Mailhot
> <nicolas.mailhot at 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 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).
> 
> 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,

-- 
Nicolas Mailhot