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.
\ \
Packagers SHOULD ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
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:
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.
fonts that use a format that bundles different font families in a single file.
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
The foundryname- prefix can optionally be skipped:
If projectname or foundryname are repeated in fontfamilyname, they can be dropped from fontfamilyname.
dejavu-fonts-common Utility subpackage with no font files inside.
google-droid-fonts - google-droid-sans-fonts
- google-droid-sans-mono-fonts
- google-droid-serif-fonts
google-droid-fonts-common Utility subpackage with no font files inside.
un-core-fonts - un-core-pilgi-fonts
- un-core-dinaru-fonts
- un-core-batang-fonts…
un-core-fonts-common Utility subpackage with no font files inside.
openoffice.org openoffice.org-opensymbol-fonts
- openoffice.org-writer
- openoffice.org-calc…
ctan-cm-lgc-fonts - ctan-cm-lgc-sans-fonts
- ctan-cm-lgc-roman-fonts
- ctan-cm-lgc-typewriter-fonts…
ctan-cm-lgc-fonts-common Utility subpackage with no font files inside.
ctan-cm-lgc-tex TEX overlay for ctan-cm-lgc fonts
(cooked up example, this page is not a TEX naming guideline)
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.
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.
The "copyright notice" field (tag #0) of the "name" table of TTF and OTF files MUST be populated and contain accurate information. Additionally, if information is provided in the "license description" (#13) or "license info URL" (#14) fields are populated, the information contained therein must also be accurate. You can use ttname
to review the metadata included with the font to check it for accuracy.
If the metadata is incorrect, packagers should work with upstream to ensure the metadata is properly populated there, so all users of the font can benefit from the corrections. If upstream is non-responsive or you are waiting on a new release for the corrections, you can also use ttname
in %prep
to correct the metadata for the Fedora package.
To view the contents of the entire name table of a font, just run:
ttname -a font.ttf
You can also use ttname to set the fields if upstream is nonresponsive to your requests to correct it.
For example, you could run this in %prep
to populate all the relevant fields with information contained in the package:
ttname -a --copyright="$(head -n1 LICENSE)" --license="$(cat LICENSE)" --license-url="http://scripts.sil.org/OFL" font.ttf
Once upon a time every Linux GUI application used the so-called Core fonts server-side X11 backend[^4]. 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.