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.



Package layout for fonts

 * 1) Fonts released upstream in separate archives MUST be packaged in separate source packages (src.rpm), unless they belong to the same font family.
 * 2) Packagers SHOULD ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
 * 3) fonts with other material such as application code, or
 * 4) different font families.
 * 5) * As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated.
 * 6) Packagers MUST package each font family in a separate (noarch.rpm) (sub)package, notwithstanding on how they applied the previous source package (src.rpm) rules. The only admitted exceptions are:
 * 7) source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine,
 * 8) font families which are designed to extend other font families with larger Unicode coverage (for example Arial Unicode, Droid Sans Fallback), in which case grouping the font family and its extension in a single (sub)package is acceptable.
 * 9) * such cases should be notified to the fontconfig maintainer and the Fedora fonts list, so the font family split can be eventually hidden from users.
 * 10) fonts that use a format that bundles different font families in a single file.
 * 11) On the other hand, the different faces of a font family MUST be packaged together in a common (noarch.rpm) (sub)package, and not spread over different (sub)packages.

Naming
Fedora font packages are named [foundryname-]projectname[-fontfamilyname]-fonts, in lowercase.

Clarifications

 * 1) For Fedora purposes a “foundry” is an entity that publishes a set of fonts with consistent font QA rules. Thus a generic hosting service such as Sourceforge is not a foundry, but the Open Font Library is.
 * 2) It is good practice to contract foundryname- in a short prefix.
 * 3) The foundryname- prefix can optionally be skipped:
 * 4) * for entities that never released more than one font family, or
 * 5) * when the font project and the publishing entity are one and the same.
 * 6) If projectname or foundryname are repeated in fontfamilyname, they can be dropped from fontfamilyname.
 * 7) When foundryname, projectname or fontfamilyname contain the font or fonts affix, this affix should be dropped from them.
 * 8) -fontfamilyname should not be included in the srpm name of a package that includes several different font families.
 * 9) If any element of the naming contains spaces, they should be replaced by “-”.
 * 10) The use of the -fonts suffix is not dependant on the actual number of font files in the package.

When in doubt, ask the mailing list for clarification.

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.

Technical implementation
Creating font packages or subpackages in Fedora is done using the fontpackages-devel package. Its sources are published on fedorahosted in archive and git (git://git.fedorahosted.org/fontpackages.git) formats.

It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates:
 * a simple template for font source packages containing a single font family,
 * a complex template for font source packages containing several different font families.

While this package has been created by Fedora for Fedora, its content should be pretty generic. Apart from the occasional reference to this wiki as documentation source, it should not include any blatant Fedora-ism.

fontpackages evolutions can be discussed on the Fonts SIG mailing list.

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.