Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • F fontconfig
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 181
    • Issues 181
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 23
    • Merge requests 23
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • fontconfig
  • fontconfig
  • Issues
  • #188
Closed
Open
Issue created Nov 18, 2019 by Nicolas Mailhot@nim

Please add <group> → <family>

This is a part of: #200

Preamble

Because OpenType is the result of a long and bumpy evolution, and because it is not realistic to expect all existing font files to be regenerated every time this evolution adds a new capability or corrects past mistakes, OpenType specifies multiple layers of overlapping and sometimes conflicting metadata.

Due to the complexity of the result, most font creators only test the layers exercised by their target font environment (not a free desktop due to the low market share of free desktops). As a result the metadata state of the real-world font files is poor and can not be relied upon.

The usual font author workaround is to split font families into multiple blocks of technical capabilities, in separate files. Since a lot of systems use the font family to distinguish font files, that results in the creation of a large number of technical font families, intended to be assembled in a single functional font family.

Please add the family child element to group, that allows humans to inform fontconfig how to perform this assemblage.

Purpose

family contains a technical font family name, that should be assembled into the target functional font family.

It can occur multiple times within an group block.

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>
    <family>@technical_family_name_2@</family>
  </group>
</fontconfig>

Behaviour

At the end of the processing, all the font files that match one of the family elements at scan time:

  1. should have their family value rewritten to @canonical_family_name@
  2. should have their fullname value rewritten to @canonical_family_name@ SPACE @original_style_name@
    1. except for the Regular style, which is omitted from fullnameby convention
    2. except for the meta no-style variable font fullname, which requires special handling
  3. should have their original family name aliased to @canonical_family_name@.

The order of the declarations in the group block is used to choose which file to present, when several font files can satisfy a fontconfig query, and there is no technical reason to choose one over the other.

Files that were already labeled @canonical_family_name@ have implicitly the highest priority, unless @canonical_family_name@ is explicitly declared at some other level in the merge list.

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 family in the match, making it repetitive and subject to human errors.

Also, the 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.

Lastly, the way it forces a specific font version, gives little room to fontconfig to optimise query results.

A single @technical_family_name@ merge, currently requires:

<?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="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>

… finishing with:

  <alias binding="same">
    <family>@technical_family_name@</family>
    <accept>
      <family>@canonical_family_name@</family>
    </accept>
  </alias>

Multiply by each and every family in the merge list.

Minimal real-world exemple

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- SPDX-License-Identifier: MIT -->
<fontconfig>
  <group>
    <target>DejaVu Serif</target>
    <family>DejaVu Math TeX Gyre</family>
  </group>
</fontconfig>
Edited Nov 23, 2019 by Nicolas Mailhot
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking