Please add <group> → <match> → <change> → <style>
This is a part of: #200
Preamble
Mistakes in style
labeling are often lost in the noise, generated by splitting fonts over multiple files. Assembling those files reveals those mistakes. Therefore, complete assembly may require, a style
rewrite. Mistakes range from:
- obvious errors
- gratuitous use of non standard label; some font authors are repelled by the plain nature of
Regular
, even though it’s the standard applications understand - inconsistencies, forgotten after the original split into multiple files (often caused by the previous: use of
Regular
in some font blocks, and something else in others) - incompleteness: some styling information leaked into the family name, and was omitted from the style itself; this is common when font authors do not follow best practices, and apply the limitations of the earliest OpenType naming layers (Name ID 1/2), to the most recent layers (Name ID 16/17 or 21/22)
Purpose
The change
element is intended for easy rewrite of known-broken style
s, without affecting the general match logic.
Proposed syntax
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>@canonical_family_name@</target>
<match>
<family>@technical_family_name@</family>
<change>
<style>@original_style_name@</style>
<into>@canonical_style_name@</into>
</change>
</match>
</group>
</fontconfig>
Behaviour
match
directives are applied as usual. The elements in change
do not participate in group
matching.
When a font file, selected by the match
, also matches the style
value in a change
block:
- its
style
this value is rewritten into@canonical_style_name@
- its
fullname
is rewritten into@canonical_family_name@
SPACE@canonical_style_name@
the usual way (with the usualRegular
exception).
If style
was allowed to participate in the match
, additonal match
blocks would be necessary to handle the other styles. That would require:
- either writing a separate
match
block for every other style that may occur (tedious, verbose, error-prone, and not robust against publication of new font files), or - inventing an “everyone except” match syntax (complex, and requiring perfect synchronization between
match
elements) - or, supporting overlapping
match
elements (one just for the problemstyle
, the other for thefamily
in general), with tricky priorization problems (the very same problems encountered today for fonts withlang
-specific handling)
Past alternatives
The wins are less spectacular, than in the other elements of the proposed syntax. Rewriting style
, by nature, can not be factored out at the font family level, and requires the deep font file inspection, required to identify style breakage in the first place.
One could argue it is just transforming the current:
<test name="style">
<string>@original_style_name@</string>
</test>
<edit name="style">
<string>@canonical_style_name@</string>
</edit>
into
<change>
<style>@original_style_name@</style>
<into>@canonical_style_name@</into>
</change>
However, taking style
rewriting needs into account, in the new syntax, is necessary to avoid degenerating into the old syntax, every time a style
label needs fixing.
Also, the fixed style
, is used as reference in the fullname
rewriting associated with group
, so the actual amount of configuration lines, replaced by this simple line, is much larger than the edit
block alone.
While the general case is a single broken style
per family
, the syntax allows declaring as many change
blocks as necessary, factoring out the rest of the configuration for this family
.
Minimal real-world example
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>GFS Decker</target>
<!-- GFS Decker, alone in all the GFS font families
uses “Normal” instead of “Regular” as default style -->
<match>
<family>GFS Decker</family>
<change>
<style>Normal</style>
<into>Regular</into>
</change>
</match>
</group>
</fontconfig>