Re: Fontconfig language update proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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.


Nicolas Mailhot
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux