World domination plans
This page consolidates all the Fedora 11 changes proposed to the Fonts SIG so they can be discussed properly.
Bump font tools versions
As has been done previously, the tools used to build fonts (fontforge, xgridfit…) will be updated:
- at the start of the Fedora 11 cycle
- as needed during the rest of the development cycle
- just before Fedora 11 Freeze
- and hopefully not later
Every font packager is supposed to have rebuilt his fonts with the pre-freeze versions before the repository is frozen so we're sure no regression lurks and our builds can be reproduced with the tools published at release time.
Package naming
foofont variations
A few font packages do not use our strict foo-fonts naming yet but some other variation. They could be fixed.
Foundry names in font packages
Our font package naming is a lot more consistent than it used to be. Unfortunately with the repository growth some little problems have crept in. SIL fonts, for example, are alternatively named foo-fonts, sil-foo-fonts, foo-sil-fonts. This is confusing for users and new packagers.
For Fedora 11, we could adopt a strict foundry_name-font_name-fonts rule.
Exceptions and other gray cases:
- when foundry_name = font_name (for example for dejavu) there's probably no need for repetition
- should we register every Open Font Library package as oflb-foo-fonts? Or should we try to differentiate them by author?
- how should we treat fonts not published in a big site? Add a prefix preventively (for example thibault, levien…)? Exempt them?
Split big font packages on font family lines
Rationale
Several releases ago, when we had few fonts, big font packs were no problem. Users had little choice and just installed everything anyway. Nowadays, with a bigger offering, big font packs mean that a user wanting one font in pack A and another in pack B, will have to pull all the other fonts in both packs.
In the past years, we've tried to avoid mixing different fonts in a single package. Our packaging template is therefore single-font oriented. Unfortunately upstream does not always leave us much choice. For Fedora 9 and 10 we've asked packagers to consider subpackaging (leaving the actual split lines to the packager discretion). It seems this request is confusing and packagers just end up splitting along font family lines.
Also, recent reviews show having packagers reinvent subpackaging separately does not work too well. There are just too many ways to shoot oneself in the foot.
For Fedora 11, we could use clear simple common splitting rules, applied retroactively to historic packages.
(The "s" in -fonts would then ultimately be a lie, but is it a big problem?)
Plumbing
To proof the concept, and provide a generic example, dejavu has been converted in Fedora 11 Rawhide. The package has been split into:
- 6 font subpackages: sans/serif/mono in full and lgc versions
- 1 -common subpackage they all depend on: common documentation, common font directory
- 2 -compat packages, to streamline upgrades: one package that obsoletes the old dejavu-full packages, and requires the new ones, and another for the dejavu-lgc packages. Those packages will be retired after one distro cycle (in F12)
Then the macros used have been split in a separate package that could serve as support for every Fedora fonts package. It's been tested with:
- dejavu: multiple font families, multiple fontconfig files,
- theokritos: single font family and fontconfig file,
- vera: multiple font families and no config file
This work tried to stay generic and avoid the pitfalls identified by recent package reviews:
- do not macroize summaries and descriptions, each package needs different text and rpm does not like whitespace
- do macroize the scriplets packagers forget to add
- allow one or several fontconfig files per subpackage
- allow one or several font file patterns per subpackage
Use strict lowercase names
For consistency, since font names appear in various casings in font metadata, file names, project pages, and it's useless to try to find the "best" one font per font, font packages could adopt the most common convention, and just use lowercase in package names (like others big distributions do).
Consolidated view
All those rules would result in something like this. Please complete and comment (TEX font packages not listed because they are hopeless in their current form).
Current name | Name change | Comments |
---|---|---|
edrip-fonts | apanov-edrip-fonts | Prepare for other fonts by Andrey Panov |
kacst-fonts | arabeyes-kacst-fonts | Maybe also needs splitting? |
bitstream-vera-fonts |
|
|
|
|
|
fonts-hebrew-fancy | culmus-fancy-fonts | Why wasn't it renamed with culmus? |
|
|
|
ecolier-court-fonts | Is it worth splitting? | |
freefont |
|
|
ghostscript-fonts | Needs to be split but at the same time finding OTF replacements would probably be better | |
|
|
kpld.net fonts |
inconsolata-fonts | levien-inconsolata-fonts | Prepare for other Levien font packages |
liberation-fonts |
|
|
mathml-fonts | ??? | Needs to be split or killed |
mgopen-fonts |
|
Magenta open fonts |
|
|
|
|
|
Open Font Library packages |
paktype-fonts | Seems it needs some update and splitting | |
|
|
SIL packages |
thaifonts-scalable |
|
|
tiresias-fonts |
|
Since upstream proposes separate archives, should never have been packaged in a single rpm |
|
|
|
|
Someone needs to check those (renaming, splits…) |
Comps
Our font package number is getting high, so splitting the @fonts group may be a good idea.
insert cool split proposal here
Also, it's probably a good idea to create a few comps group for related font packages (@sil-fonts, @gfs-fonts, @dejavu-fonts, @kpld-fonts, etc). Groups with less than ten packages are not unknown in Fedora history.
insert minimal number of packages for a fonts group to be viable
Packaging guideline changes
Fontconfig
A packaging guideline change has been proposed to make font and fontconfig packages follow the same rules. It's on hold while upstream answers an FHS question.
Subpackaging
Do people feel font subpackaging deserves a separate package template, approved as a guideline? Or is 'just copy dejavu' sufficient? Should the related macros be put in a separate build-required package (and which one)?
Distribution support
- The comps changes need support by the comps benevolent dictator.
- The macro changes need support by the rpm maintainer (or do we want to put them somewhere else?).
- The renamings need infra & packagedb help.