From Fedora Project Wiki

No edit summary
(Deprecate this page.)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{OldGuidelinePage|FontsPolicy}}
{{CompactHeader|fonts-sig}}
{{CompactHeader|fonts-sig}}


Line 5: Line 6:
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_considerations_for_fonts| legal page]].
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_considerations_for_fonts| legal page]].


{{Anchor|build-from-sources}}
<BR><BR>
== Building from sources ==
{{Admon/note|What is a font family?|{{:Fonts spec template notes/font-family}}}}


Fonts '''SHOULD''' be built from source whenever upstream provides them in a source format<ref>As documented in our general [[Packaging/Guidelines#SourceRequirementExceptions|packaging guidelines]].</ref>. 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.
== Package layout for fonts ==


{{Anchor|no-handler-deps}}
# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.
== Install-time dependencies ==
# Packagers '''SHOULD''' ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
## fonts with other material such as application code, or
## different font families.
#* 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.
# 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:
## 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,
## 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.
##* such cases should be notified to the fontconfig maintainer and the Fedora [[Fonts SIG mailing lists|fonts list]], so the font family split can be eventually hidden from users.
## 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<ref>


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.
'''Rationale:'''


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.
As noted in the [[Packaging/Guidelines#Bundling |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.


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.
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.


{{Anchor|no-new-core-fonts}}
The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families.
== Core fonts ==


Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backend<ref>Fonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper] written shortly before projects massively migrated to client-side fonts.</ref>. 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.
Lastly, multi-font packages unnecessarily complexify font auto-installation.</ref>.
 
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.
 
{{Anchor|grouping}}
== Grouping ==
 
{{:Comps_fonts_rules}}


== Naming ==
== Naming ==
Line 155: Line 155:
|-
|-
|}
|}
<noinclude>
Notes:
<references/>


{{Anchor|build-from-sources}}
== Building from sources ==
Fonts '''SHOULD''' be built from source whenever upstream provides them in a source format<ref>As documented in our general [[Packaging/Guidelines#SourceRequirementExceptions|packaging guidelines]].</ref>. 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<ref>Built from the [[pkgdb:fontpackages|fontpackages]] srpm.</ref>. Its sources are published on [http://pagure.io/ Pagure] in [https://pagure.io/fontpackages archive] and git (https://pagure.io/fontpackages.git) formats.
It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates:
* a [[Simple fonts spec template|simple template]] for font source packages containing a single font family,
* a [[Fonts spec template for multiple_fonts|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 [[Fonts SIG mailing lists|mailing list]].
{{Anchor|no-handler-deps}}
== 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.
{{Anchor|grouping}}
== Grouping ==
{{:Comps_fonts_rules}}
== Licensing Information in Metadata ==
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 [[User:Patches/ttname|<code>ttname</code>]] 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 <code>ttname</code> in <code>%prep</code> to correct the metadata for the Fedora package.
=== Checking the metadata with ttname ===
To view the contents of the entire name table of a font, just run:
<pre>ttname -a font.ttf</pre>
=== Correcting the metadata with ttname ===
You can also use ttname to set the fields if upstream is nonresponsive to your requests to correct it.


== Package layout for fonts ==
For example, you could run this in <code>%prep</code> to populate all the relevant fields with information contained in the package:
<pre>ttname -a --copyright="$(head -n1 LICENSE)" --license="$(cat LICENSE)" --license-url="http://scripts.sil.org/OFL" font.ttf</pre>


# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.
{{Anchor|no-new-core-fonts}}
# Packagers '''SHOULD''' ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:
## fonts with other material such as application code, or
## different font families.
#* 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.
# 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:
## 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,
## 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.
##* such cases should be notified to the fontconfig maintainer and the Fedora [[Fonts SIG mailing lists|fonts list]], so the font family split can be eventually hidden from users.
## 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<ref>


'''Rationale:'''
== Core fonts ==


As noted in the [[Packaging/Guidelines#Bundling |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.
Once upon a time every Linux GUI application used the so-called ''Core fonts'' server-side X11 backend<ref>Fonts accessed through the original ''core'' X protocol, using tools like ''mkfontdir'', ''xfs'', ''/etc/X11/fontpath.d/'', ''XLFD'' strings, etc. See also this [http://keithp.com/~keithp/talks/xtc2001/paper/ paper] written shortly before projects massively migrated to client-side fonts.</ref>. 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.


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.
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 functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families.
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.


Lastly, multi-font packages unnecessarily complexify font auto-installation.</ref>.
== Notes ==
<noinclude>
Notes:
<references/>
<references/>
</noinclude>


{{:Fonts_SIG_signature}}
{{:Fonts_SIG_signature}}
[[Category:Fonts packaging|Packaging policy]]
[[Category:Fonts packaging|Packaging policy]]
[[Category:Packaging guidelines]]

Latest revision as of 20:01, 21 December 2018

This is an old copy of a packaging guideline, preserved here in the wiki while we complete the transition to the Fedora documentation system. The current version is located at https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/. Please update your bookmarks.

A page of the Fonts Special Interest Group

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.



What is a font family?
  • A font family corresponds to one entry in GUI font lists. For example, DejaVu Sans, DejaVu Serif and DejaVu Sans Mono are three different font families.
  • A font family is subdivided in faces or styles. DejaVu Sans Normal, DejaVu Sans Bold, DejaVu Sans Condensed Italic are three faces of the DejaVu Sans font family.
  • A font-metadata aware tool such as gnome-font-viewer[1] or fontforge[2] can be used to check the font family name and the font face/style declared by a font file.

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:
    1. fonts with other material such as application code, or
    2. different font families.
    • 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.
  3. 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:
    1. 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,
    2. 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.
      • 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.
    3. fonts that use a format that bundles different font families in a single file.
  4. 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[3].

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:
    • for entities that never released more than one font family, or
    • when the font project and the publishing entity are one and the same.
  4. If projectname or foundryname are repeated in fontfamilyname, they can be dropped from fontfamilyname.
  5. When foundryname, projectname or fontfamilyname contain the font or fonts affix, this affix should be dropped from them[4].
  6. -fontfamilyname should not be included in the srpm name of a package that includes several different font families.
  7. If any element of the naming contains spaces, they should be replaced by “-”.
  8. 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.

Examples

Font package naming examples
Source package (src.rpm) Binary (sub)package Description
Fonts Other Fonts Other
apanov-heuristica-fonts apanov-heuristica-fonts “Heuristica” font family published by Andrey Panov, “apanov”.
sil-abyssinica-fonts sil-abyssinica-fonts “Abyssinica SIL” font family published by the “SIL” foundry.
oflb-brett-fonts oflb-brett-fonts “BrettFont” font family published on the “Open Font Library”, “oflb” foundry.
dejavu-fonts
  • dejavu-sans-fonts
  • dejavu-sans-mono-fonts
  • dejavu-serif-fonts
 The three “DejaVu” font families self-published by the “DejaVu” project.
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
 The three “Droid” font families published by “Google”, as part of its “Droid” release.
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 published by the “UN” project.
un-core-fonts-common Utility subpackage with no font files inside.
openoffice.org openoffice.org-opensymbol-fonts The “OpenSymbol” font family published as part of “openoffice.org”.
  • 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…
 “CM LGC” font families published by the “CTAN” foundry.
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)

Building from sources

Fonts SHOULD be built from source whenever upstream provides them in a source format[5]. 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[6]. Its sources are published on Pagure in archive and git (https://pagure.io/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.

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.


Licensing Information in Metadata

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.

Checking the metadata with ttname

To view the contents of the entire name table of a font, just run: 

ttname -a font.ttf

Correcting the metadata with ttname

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

Core fonts

Once upon a time every Linux GUI application used the so-called Core fonts server-side X11 backend[7]. 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.

Notes

  1. ↑ Simple, but sadly not available in each and every Fedora release.
  2. ↑ Type <CTRL> + <SHIFT> + <F> to open the font metadata window in fontforge.
  3. ↑ Rationale: 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. 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. The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families. Lastly, multi-font packages unnecessarily complexify font auto-installation.
  4. ↑ To avoid foofont-fonts packages.
  5. ↑ As documented in our general packaging guidelines.
  6. ↑ Built from the fontpackages srpm.
  7. ↑ Fonts accessed through the original core X protocol, using tools like mkfontdir, xfs, /etc/X11/fontpath.d/, XLFD strings, etc. See also this paper written shortly before projects massively migrated to client-side fonts.


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.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:FontsPolicy&oldid=530771"