GitLab

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, a tag 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>

1. assigns the 700 value on the weight axis, to all the variants, containing the Bold keyword in their style name (after group-ing, and applying the new-style / style-prefix rewritings of style). 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.

2. tells fontconfig, that it can use the 700 value in weight, to synthesise styles from variable fonts (if the group block includes variable fonts with a weight 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.