[Fontconfig] Fontconfig language update proposal

[Akira TAGOH]

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. this was just a proposal from a
requester. not *already doing*. even not started yet.
That is too low-level and can be broken easily if we simply allow to
set it as is.
To get back to my point, we don't want to have multiple language
engines to parse and interpret something in configuration for
fontconfig. we may have some interface for the input for
fontvariations property but the output isn't for fontconfig. no need
to interpret it at all. in that sense, we just need to build a string
in that format for Pango and other libraries. I meant to it. that
would be completely different story to have YAML you are saying.

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

> 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. or am I missing something? or
wasn't realized we started talking about different topics?

> The result is an house of cards. It is not viable long term. Next time
> the OpenType spec adds some twists, or experience shows the low-level
> stuff needs tweaking, those thousands of instructions will need changing
> accordingly.
>
> My proposal shrinks the configuration to the bare minimum human info
> fontconfig does not autodetect today. It can only shrink further, as
> fontconfig gets smarter. It does not suffer from all the low-level
> prioritization interactions crap, because the config files posit a
> common handling strategy engine-side, instead of considering that every
> single font file on system needs a different management strategy (which
> is completely insane, current fontconfig syntax makes exceptions the
> general case, instead of keeping them as exceptions).

I see.

> > Again, there shouldn't be that difference between them. that would be
> > "complicated vs simple" or "generic vs dedicated". both have pros and
> > cons.
>
> Stop here. generic is the only way forward.

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.

Anyway, I don't have more comments here. will review your requests and
update issues.

>
> The average free desktop systems uses hundreds if not thousands of font
> files. It's been a *very* long time since a free desktop was limited to
> the same handful of xorg font files.
>
> Do you want me to count the number of font files in Plex alone? In
> Droid? In Fira? In Noto?
>
> You need to go generic or give up on fontconfig as the system font
> manager.
>
> There are no magical fairies out there that will decline a generic
> strategy for all the font files installed on free desktop systems, using
> the hundreds of configuration lines the current syntax requires.
>
> Regards,
>
> --
> Nicolas Mailhot



-- 
Akira TAGOH