Le 2019-08-07 11:07, Akira TAGOH a écrit :
Hi Akira,
* Replacement
I'd propose to drop those unnecessary and problematic languages for a
font from fontconfig cache instead of testing a language at runtime.
it can be done like:
I see this got lost in my ML queue during vacations.
From a font packager PoW I don’t hugely care about this kind of detail.
I’d love to have some simplified fontconfig declarative syntax, that
says :
– "this font family or specific font file file works for this list of
locales"
– or the reverse, "this font family or specific font file does not work
for this list of locales"
And then have fontconfig do the correct thing, as defined by the
fontconfig maintainers, taking into account their real-world experience
with real-world fonts.
The correct thing may be to auto-blacklist all locales that overlap with
declared good locales, or keep the glyphs as last-chance fallback, etc.
I don’t heavily care. That’s generic font processing strategies
fontconfig side. They can change over time, without requiring me to
rewrite my font declarations.
The problem of the fontconfig syntax right now, is that is is too
low-level. It forces font user to define strategies for fontconfig
instead of just giving human knowledge, and as a result those strategies
are not homogeneous, and require a rewrite of all fontconfig
configuration files every time you, as our fontconfig authority, decide
the correct thing needs to change
We have this problem for all high-level font packaging objective defined
in current or proposed font packaging guidelines. I think it should not
be hard to agree the high-level objectives are the correct thing to do.
But we don’t manage to perform them at scale, because
1. the low-level fontconfig syntax in not very human friendly
2. you, and others, are always afraid the implementation strategy will
need adjusting later, and very few people want to invest writing
fontconfig files that will need rewriting every time this implementation
strategy changes.
fontconfig conf files are too much of a fontconfig programming language.
To scale, they should evolved towards simplified human declarations of
what font files are appropriate for (the low-level syntax can be kept
for special-cal overrides or implementation change experiments).
Regards,
--
Nicolas Mailhot
_______________________________________________
fonts mailing list -- fonts@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to fonts-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/fonts@xxxxxxxxxxxxxxxxxxxxxxx
