Please add <group> → <axis>
This is a part of: #200
Preamble
The appearance of variable fonts makes it necessary to map traditional font families to variable font families, and back. It is unrealistic to expect variable fonts to reach the coverage of traditional fonts quickly. Therefore, applications will have to mix and match both kinds of fonts for complex international text.
Purpose
The axis
element in an group
block, is used to declare mappings between traditional families (that declare styles) and variable families (that may declare instances, or not).
Proposed syntax
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
<group>
<target>@canonical_family_name@</target>
<axis>
<name>@axis_name@</name>
<step>
<name>@step_name@</name>
<value>@step_value@</name>
</step>
</axis>
</group>
</fontconfig>
Behaviour
The axis
element in an group
block is used to declare mappings for a specific variation axis:
- the
name
sub-element specifies a specific variation axis; for example,weight
(alternatively, atag
sub-element could be used to select axis by human-unfriendly 4-letter tag ID). - the
step
sub-element is used to name and a point in the axis scale
axis
is not used to declare variable family names. Those belong in the group
block like other families assembled into @canonical_family_name@
.
step
is intended to match style
components. For example a declaration of:
<axis>
<name>weight</name>
<step>
<name>Bold</name>
<value>700</name>
</step>
</axis>
-
assigns the
700
value on theweight
axis, to all the variants, containing theBold
keyword in theirstyle
name (aftergroup
-ing, and applying thenew-style
/style-prefix
rewritings ofstyle
). This is necessary because some projects (ie IBM Plex) do not use consistent values for the same keywords over all their font files, breaking substitution in apps. -
tells fontconfig, that it can use the
700
value inweight
, to synthesise styles from variable fonts (if thegroup
block includes variable fonts with aweight
axis).
An axis
should contain multiple step
elements.
Style synthesis
Fontconfig should synthesise styles from all the named steps declared in an group
block for the default
- width
- weight
- slant/italic
… OpenType axes. (The OpenType spec recommends using slant or italic, but not both of those).
The generated styles should be named:
width
SPACE weight
SPACE slant
omitting the qualifiers for the default Regular
value of an axis, and using Regular
when all values are the default.
When variable instances, with the same name, or the same combination of width
+ weight
+ slant
values, are already present in some files, concerned by the group
block, they are masked by the axis
declaration.
Selection between non-variable styles, with the same name, and synthetised styles, follows the usual group
priorization rules (ie if the variable family is first in group
, and satisfies the rest of the query, it wins).
Variable instance synthesis
When it is not possible, to return a variable combination, corresponding to a specific query (typically, because coverage is insufficient in the variable part of the font family, for a particular lang, forcing fallback to its non-variable components), fontconfig should return the closest matching traditional style.
Distance is computed from the Regular
origin of each axis, starting with the slant
/italic
, then the weight
, then the width
, then the optical size
axis.
For example, if the files concerned by group
do not include any matching variable data for weight
, but the configuration declares:
<axis>
<name>weight</name>
<step>
<name>Light</name>
<value>300</name>
</step>
<step>
<name>Regular</name>
<value>400</name>
</step>
<step>
<name>Bold</name>
<value>700</name>
</step>
</axis>
A query for the 200
weight should return Light
, a query for 600
should return Regular
, and a query for 900, Bold
.
Substitution
axis
mapping only applies to the font files, concerned by the group
block. The mappings are not applied to any substituted font (via like
or another aliasing mecanism).
Naming normalization
While this proposal does not force any particular style
naming policy, it should be obvious that reliable variable to traditional mapping will depend on strong style
naming conventions, such as the ones defined by Microsoft in its WPF font selection model.
This proposal does not mandate applying Microsoft’s naming rules. Any style naming policy will work, as long as it is used consistently in all the technical families concerned by the group
block.