Le 2019-11-28 12:19, Akira TAGOH a écrit :
On Thu, Nov 28, 2019 at 6:36 PM Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx> wrote:
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).
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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
