From Fedora Project Wiki

No edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 10: Line 10:
This change is part of the [[Fonts SIG Fedora 11 packaging changes_(2008-11-08)#Split_big_font_packages_on_font_family_lines|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.
This change is part of the [[Fonts SIG Fedora 11 packaging changes_(2008-11-08)#Split_big_font_packages_on_font_family_lines|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 [[Packaging:FontsPolicy#Font_bundles|one paragraph]] of our current font policy.
The change consists of the rewording [[Packaging:FontsPolicy#Font_bundles|one section]] of our current font policy.
 
== Previous wording ==
 
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.
 
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.
 


{{Admon/note|What is a font family?|{{:Fonts spec template notes/font-family}}}}
{{Admon/note|What is a font family?|{{:Fonts spec template notes/font-family}}}}


</noinclude>{{Anchor|package-layout}}{{Anchor|splitting}}
</noinclude>{{Anchor|package-layout}}{{Anchor|splitting}}
== Package layout of font packages ==
== Package layout for fonts ==


# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.
# Fonts released upstream in separate archives '''MUST''' be packaged in separate source packages (''src.rpm''), unless they belong to the same font family.
Line 41: Line 26:
## 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.
## 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.
##* 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.
## 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>


<noinclude>
'''Rationale:'''
== 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 54: Line 37:
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/>
Line 62: Line 44:
{{:Fonts_SIG_signature}}[[Category:Fonts packaging guideline change proposals|2008-12-21, Splitting]]
{{:Fonts_SIG_signature}}[[Category:Fonts packaging guideline change proposals|2008-12-21, Splitting]]
</noinclude>
</noinclude>
[[Category:Archived packaging guideline drafts]]

Latest revision as of 02:38, 25 February 2009

A page of the Fonts Special Interest Group


FPC
This proposal was reviewed and approved by FPC on 2009-01-06.
FESCO
FPC's conclusions were ratified by FESCO on 2009-01-16.

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.

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

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.


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=Archive:PackagingDrafts/Font_package_splitting_rules_(2008-12-21)&oldid=82571"