No edit summary |
No edit summary |
||
Line 28: | Line 28: | ||
## historic Latin fonts which share a common designer, and are intended to be used together, as evidenced by their name (for example ''Liberation Sans'', ''Liberation Serif'' and ''Liberation Mono''). In that case splitting them in different subpackages or not is left to the packager discretion. | ## historic Latin fonts which share a common designer, and are intended to be used together, as evidenced by their name (for example ''Liberation Sans'', ''Liberation Serif'' and ''Liberation Mono''). In that case splitting them in different subpackages or not is left to the packager discretion. | ||
## fonts that use a format that bundles different font families in a single file. | ## 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 | # 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:''' | |||
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. | 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. | ||
Line 38: | Line 38: | ||
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 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. | Lastly, multi-font packages unnecessarily complexify font auto-installation.</ref>. | ||
<noinclude> | |||
Notes: | Notes: | ||
<references/> | <references/> |
Revision as of 10:09, 18 January 2009
Foreword
This change is part of the list of cleanups discussed on the fonts and devel lists since november 2008. It is intended to make rules clearer for new and existing packagers, by rewording rules in a more succinct and imperative manner. Experience shows that too much leeway just results in packagers wasting time as they find new “interesting” ways to interpret the guidelines.
The change consists of the rewording one section of our current font policy.
Package layout of font packages
- Fonts released upstream in separate archives MUST be packaged in separate source packages (src.rpm), unless they belong to the same font family.
- 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 list, so the font family split can be eventually hidden from users.
- historic Latin fonts which share a common designer, and are intended to be used together, as evidenced by their name (for example Liberation Sans, Liberation Serif and Liberation Mono). In that case splitting them in different subpackages or not is left to the packager discretion.
- 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[3].
Notes:
- ↑ Simple, but sadly not available in each and every Fedora release.
- ↑ Type <CTRL> + <SHIFT> + <F> to open the font metadata window in fontforge.
- ↑ 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.