GitLab

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>