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
  • #190
Closed
Open
Issue created Nov 18, 2019 by Nicolas Mailhot@nim

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 styles, 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 usual Regular 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 problem style, the other for the family in general), with tricky priorization problems (the very same problems encountered today for fonts with lang-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>
Edited Nov 26, 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