Please add <group> → <match>
This is a part of: #200
Purpose
The match
container in group
is intended to permit the declaration of more complex matching patterns.
This is necessary, when the state of family
metadata inside font files, is insufficient, to be relied upon for matching.
Proposed syntax
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>@canonical_family_name@</target>
<family>@technical_family_name_1@</family>
<match>
<fullname>@technical_fullname_2@</fullname>
</match>
<match>
<family>@technical_family_name_3@</family>
<style>@original_style_name@</style>
</match>
</group>
</fontconfig>
Behaviour
All the elements specified inside match
must have the declared value for the result to participate in the assembly. Otherwise, it behaves the same as a plain family
entry.
One could allow fullname
directly inside group
to avoid a match
level. However, match
would be still required to perform operations, that involve more than a single field (matching on several fields or performing specific changes on a match).
Past alternatives
A similar result was obtained in the past with multiple uses of the following pattern.
Unfortunately, this pattern requires identifying beforehand all the styles present in the technical font families. Therefore, it is not robust against font changes.
Also, it does not factor out what to do for every pattern in the match, making it repetitive and subject to human errors.
Lastly, human must remember the Regular
and variable special cases.
Even with a motivated human, the number of declaration blocks required to list all the styles present in the font files limits its scaling to simple font families.
The way it forces a specific font version, gives little room to fontconfig to optimise its query results.
Furthermore, the aliasing requirement is especially tricky to express correctly in a generic way.
The rewriting requirement is similar to this block:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<match target="scan">
<test name="family">
<string>@canonical_family_name@</string>
</test>
<edit name="fontversion">
<int>2</int>
</edit>
</match>
… followed by multiple blocks of:
<match target="scan">
<test name="fullname">
<string>@technical_fullname@</string>
</test>
<test name="family">
<string>@technical_family_name@</string>
</test>
<test name="style">
<string>@original_style_name@</string>
</test>
<edit name="family">
<string>@canonical_family_name@</string>
</edit>
<edit name="fullname">
<string>@canonical_family_name@ @original_style_name@</string>
</edit>
<edit name="fontversion">
<int>1</int>
</edit>
</match>
</fontconfig>
Minimal example
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>Foo</target>
<match>
<fullname>Broken Foo</fullname>
</match>
</group>
</fontconfig>
Real-world example
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>GFS Didot</target>
<!-- Because GFS leaked “GFS Didot” inside the
“GFS Artemisia Bold” metadata, it can not be
used for reliable matching without complex
priorization rules -->
<match>
<fullname>GFS Didot Bold Italic</fullname>
</match>
<match>
<fullname>GFS Didot Bold</fullname>
</match>
<match>
<fullname>GFS Didot Italic</fullname>
</match>
<match>
<fullname>GFS Didot Regular</fullname>
</match>
</group>
</fontconfig>