Packaging:FontsPolicy

Legal considerations

The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our legal page.

Building from sources

Fonts SHOULD be built from source whenever upstream provides them in a source format. Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes.

Install-time dependencies

Font packages in a generic format (TTF, OTF) are resources and MUST NOT force the installation of a particular font handler through direct or indirect Requires. Fonts can be used by many different software stacks, including outside an X11 context, you should not choose one of them in the stead of users.

Execution of stack-specific helpers in scriptlets is allowed, as long as it's conditioned on the presence of those helpers on the system, does not force their installation for the font package, and does not block package installation in their absence.

Likewise, installation of stack-specific configuration files is allowed, if they have no effect in the absence of this software stack, and are auto-discovered on installation of the software stack package.

Core fonts

Once upon a time every Linux GUI application used the so-called Core fonts server-side X11 backend. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (fontconfig). Nowadays almost no modern Linux GUI application uses the Core fonts backend. Few (if any) people are willing to fix its remaining bugs.

Therefore, unless your font has previously been registered in Core fonts, and the problems triggered by this font hopefully fixed, you SHOULD NOT declare it there. This is especially true of fonts in modern (TTF or OTF) formats.

The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to fontconfig like everyone else a long time ago.

Grouping

Fonts for a particular linguistic region used to be bundled in fonts-region packages. Nowadays this practice is frowned upon, fonts package naming reflects upstream naming like in any other Fedora package, and grouping is achieved through comps groups.

• Font packages in a legacy format (not TTF or OTF) MUST be registered in the legacy-fonts group.
• Font packages in a non-legacy format (TTF or OTF):
  1. MUST be registered in the fonts group:
     • except when they don't have an active upstream, in which case putting them in legacy-fonts is fine.
  2. SHOULD also be registered in every applicable xxx-support localization group:
     • except groups that only require glyphs in the basic latin range.
     • if a font package adds support for a script previously not supported by Fedora the associated localization groups MUST be created and filed, and the relevant localization teams notified.
  3. SHOULD be declared optional, unless:
     • they add support for a new script, in which case they MUST be declared required in the associated localization groups.
     • they add better support for already supported scripts, in which case, if the localization team in charge of each localization group agrees:
       • they can replace existing fonts as mandatory if this script is not covered by distribution-wide default fonts.
       • they can replace existing fonts as default if this script is covered by distribution-wide default fonts.

Font bundles

As noted in the Packaging Guidelines, Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.

Sometimes local groups publish a collection of fonts of different origins and different licensing in a single archive. In that case the interested packager SHOULD ask this upstream to break up its archive in different files. If upstream refuses the packager MAY base a single src.rpm on the collection archive, but he MUST make sure each bundled font set ends up in a different, appropriately licensed sub-package.

When a project is the upstream of several font families, which are all licensed the same way, and released on the same dates, in a single archive, the packager MAY create a single package. However the packager SHOULD consider splitting each font family in a different sub-package, so users can install only the font families they care about.

Multi-source packages are difficult to maintain and confusing to users. In addition:

• fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.
• multi-family packages force users to install fonts they may not care of or even like just to get the other fonts in the package.

As a rule, try to produce small simple user-friendly mono-family font packages that will be easy to maintain (you should however strive to group different faces of the same font family in the same package). Avoid grouping unrelated fonts in a single package.

Fonts in Fedora
The Fonts SIG takes loving care of Fedora fonts. Please join this special interest group if you are interested in creating, improving, packaging, or just suggesting a font. Any help will be appreciated.