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(a)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
--
Akira TAGOH