No edit summary |
|||
| Line 21: | Line 21: | ||
This proposal was discussed the [[Packaging/Minutes/20080826|2008-08-26]]. | This proposal was discussed the [[Packaging/Minutes/20080826|2008-08-26]]. | ||
{{:Fonts_SIG_signature}}[[Category:Fonts packaging guideline change proposals|Bundles]] | {{:Fonts_SIG_signature}}[[Category:Fonts packaging guideline change proposals|2008-07-04, Bundles]] | ||
Latest revision as of 17:53, 7 December 2008
The following paragraph is proposed for addition to our current font guidelines.
Font bundles
Different font sources MUST NOT be used in the same package. Each font project (different licensing, different release cycle, different version, different source archive) MUST be packaged separately. As an exception projects that publish raw font files (.otf/.ttf) with no archive wrapper MAY be the object of a multi-source package. In that case the packager SHOULD contact upstream and ask it to publish a proper versionned font archive including a detached .txt license file.
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 mono-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 he 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.
FPC minutes
This proposal was discussed the 2008-08-26.
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.