Hi,
* Summary Let's drop unnecessary laguages from fontconfig cache instead of checking it at runtime.
* Background We have a template[1] to apply for certain language only. this is necessary for languages particularly which has similar coverage like CJK and Arabic etc. However this evaluation always happens when applications are going to query a font with API. the one might be trivial but it might be not if a lot of queries happens.
* 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:
<match target="scan"> <test name="family"> <string>font name</string> </test> <edit name="lang" mode="assign"> <minus> <name>lang</name> <langset> <string>xx</string> ... </langset> </minus> </edit> </match>
This is evaluated only when creating/updating fontconfig caches by fc-cache. then the targeted cache doesn't have it and matcher won't pick it up for a certain language anymore.
Well, the recipe is a bit complicated. we may need a syntax sugar for that though.
Any thought?
[1].. https://fedoraproject.org/wiki/Fontconfig_packaging_tips#Locale-specific_ove...
Hi Ankira,
I'm not sure this would work from an organisational POW. You're proposing a negative. People usually know positives, what a font file is used for.
So, from a people's POW, a rule that tells fontconfig "use this file for that set of locales, hide conflicting locales, only use it for non-conflicting locales if there is no better match" would work better
Thanks for the comment.
You're right. the inclusive way would be much better to understand than the exclusive way. it can be still accomplished like this:
<match target="scan"> <test name="family"> <string>FAMILY NAME</string> </test> <edit name="lang" mode="assign"> <minus> <name>lang</name> <minus> <name>lang</name> <langset> <string>XX</string> ... </langset> </minus> </minus> </edit> </match>
But this still respects the glyph coverage in a font. if one adds languages only which isn't actually supported in a font, this ends up no lang in cache then. that was a concern on this. the exclusive way can drops only problematic languages. if one wants to use it for non-conflicting languages but non-primary purpose of fonts (i.e. likely to be missing in lang list to include the above), this way will miss an opportunity to do.
On Thu, Aug 8, 2019 at 3:21 PM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Hi Ankira,
I'm not sure this would work from an organisational POW. You're proposing a negative. People usually know positives, what a font file is used for.
So, from a people's POW, a rule that tells fontconfig "use this file for that set of locales, hide conflicting locales, only use it for non-conflicting locales if there is no better match" would work better
Nicolas Mailhot
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,
-
Akira TAGOH -
Nicolas Mailhot