Shipping fonts in Fedora (FAQ)

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Why all naming churn, font packages got renamed twice?)
(Why were provides for the old package names not added during naming changes?)
Line 245: Line 245:
=== Why were provides for the old package names not added during naming changes? ===
=== Why were provides for the old package names not added during naming changes? ===
The historic density of font package dependencies in Fedora is small and the changes were announced at the beginning of the Fedora 11 cycle so it is felt it is quite possible and desirable to do a clean break and not carry on indefinitely old provides in the repository metadata.
The historic density of font package dependencies in Fedora is small and the changes were announced at the beginning of the Fedora 11 cycle so we feel it is quite possible and desirable to do a clean break and not carry on indefinitely old provides in the repository metadata.
This is even more true for transient package names that only existed a few weeks before [[FPC]] made us [[#fpc_renaming|rename]] them.
This is even more true for transient package names that only existed a few weeks before [[FPC]] made us [[#fpc_renaming|rename]] them.

Revision as of 10:34, 17 January 2009

A page of the Fonts Special Interest Group

This page is intended to help packagers manage existing or future packages that embed font files. It was written at the occasion of the Fedora 11 fonts packaging guidelines change and answers most questions asked during the subsequent distribution font audit.


Is this page a Fedora guideline?

Even though this page is not itself an official Fedora guideline, it was written to explain the rationale behind our current guidelines, and should not conflict with them. In case of conflict the guidelines pages always take precedence.

What is a font file?

For the purposes of this page a font file is a file using the .ttf, otf, .ttc, .pfa or .pfb extensions[1].

What does Fedora require of me?

Fedora guidelines require packaging of every font file in the distribution in a font package or subpackage complying with our fonts packaging guidelines.

Do I need to change my package in stable releases in addition to Rawhide/devel?

You should only perform fonts guidelines conformance changes of existing packages in Rawhide, unless you identify a licensing problem that needs to be taken care of in all branches.

Can I import my new package in stable releases in addition to Rawhide/devel?

Importing new packages will work in all branches. Our guidelines are compatible with the font stacks available in all our current supported releases[2].

What is a compliant font (sub)package?

  • A guidelines-compliant font (sub)package contains a single font family, packed with the %_font_pkg rpm macro, and no other material (except for eventual directory ownership and licensing or other documentation files).
  • It is referenced in the appropriate comps group.
  • It has a page in the wiki we can reference in release notes. To create such a page use this template.

What is this font family thing?

  • 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[3] or fontforge[4] can be used to check the font family name and the font face/style declared by a font file.

How many font files can I put in a font (sub)package?

You can put as many font files in a font (sub)package as you want, as long as they correspond to the same font family. If your srpm includes files associated to different font families, you need to create one subpackage per font family.

See also our official font package splitting guidelines.

I can not comply, the tools my package uses force a specific font file installation!

Tools have bugs and limitations and this has never been a good reason to ignore distribution guidelines. You are responsible for your packaging and all the scripts and other tools involved in this process. If their operational mode conflicts with Fedora guidelines it's your responsibility to report the problem upstream to get it fixed, and work around the problems in your package in the meanwhile.

But my application crashes if I remove the font file(s)!

Then add dependencies on the guidelines-compliant font (sub)packages that provide the files you need, and either patch your application to look for them here or add symlinks with the filenames it expects in your package. See also this question.

Where should my fonts symlinks point?

A properly packaged font file will be installed in a subdirectory of %_fontbasedir. %_fontbasedir is defined by the fontpackages-devel package.

Should I use package name or file name dependencies?

It seems package names are preferred right now.

My dependency does not work in Rawhide, I'll try later!

Many font packages were reorganised in Rawhide during the Fedora 11 cycle so dependencies on pre-Fedora 11 package names are likely to fail. It won't get better later, just check the package names in Rawhide and adapt your package.

Why should I bother, my font use is limited/private/controlled/hidden/etc?

Bundling of font files falls into one of the following categories:

  • private copies of font files already packaged in the distribution. Since fonts are bulky and compress poorly, you're wasting precious Fedora and user resources (bandwidth, mirror/disk space, etc). Also, application authors tend to copy fonts once and forget about them, so your copies are unlikely to be up to date, and will miss the fixes present in the dedicated Fedora font package.
  • private copies of font files that could be packaged in Fedora, but aren't yet. This is the right time to package those fonts properly so your application is not the only one benefiting from them. No font cant be assumed beforehand not to be useful to someone else.
  • private copies of font files that could not be packaged in Fedora, usually for legal reasons. You need to remove those at once as they are just as dangerous hidden inside a package as they would be exposed in a dedicated package.

Basically there is no good reason to pack fonts in non-font packages, and lots of drawbacks, which is why our guidelines are written the way they are. The deeper a font file is hidden inside an application the more likely it is to have escaped auditing so far and thus to present problems.

How can I check if my fonts present a legal risk?

You can't without identifying the fonts and tracing their source and licensing, which is the hard part of packaging fonts. Once you've done it packaging the fonts properly is only a little step, that will get you a review by people with more fonts licensing experience than you.

Do not assume the licensing of your fonts is the same as the rest of the package. It is almost never the case (besides software licenses do not apply well to fonts anyway).

How can I check if a font file is already available in the distribution?

If you're lucky your project didn't rename the font files and a simple repoquery on rawhide will find other packages that include them:

$ repoquery --repoid=rawhide -f '*DejaVuSansMono.ttf'

You need to have the rawhide/fedora-devel repository configured and enabled for this command to work.

Also, repoquery won't distinguish between actual files and symlinks. When a font file is symlinked in several packages you need to look inside them to check which one ships the symlink target.

Unfortunately font file renaming is common, so repoquery won't always be enough. In that case you need to look inside the files themselves to know their content. Once you've identified a font a yum or web search will help you find eventual packages already shipping it.

How can I identify a font file?

When it works the gnome-font-viewer command will tell you the font family name declared by a file, its style/face, and some copyright information. The fontforge font editor may provide more complete info if necessary[5].

What if my package bundles Bitstream Vera, Arev, DejaVu LGC or another Bitstream Vera font derivative?

In that case it is a good idea to replace the font files with symlinks to the corresponding DejaVu (full) packages. DejaVu (full) is the most complete fork of Bitstream Vera. It should include all the material present in Vera and its other derivatives, plus multiple fixes. Since we install the DejaVu (full) packages by default, dependencies on them will usually not pull in new packages on user systems.

What if my package bundles FreeSans, Linux Libertine, Droid or Liberation fonts?

Those are all general-purpose fonts. Replacing them with symlinks to the corresponding DejaVu (full) packages is usually the best solution, as the DejaVu (full) packages are our default general-purpose font set.

Nevertheless, do check with upstream if it had a specific reason to bundle those particular fonts (other than using the first general-purpose fonts on hand).

What if my package bundles a modified version of an existing Fedora font?

Assuming the modifications complied with the original font license and that you need them you can create a separate (sub)package for this font variant. fontconfig can manage several versions of the same font.

Though it's much better to convince the upstreams working on the same font to work together, or at least use different font names for each of the fork.

What if my package bundles the same font in several different formats?

If your application needs all those different formats, and you can not consolidate on a single one, you should probably package each different format in a separate (sub)package, so applications that do not have this limitation can only install one of them.

But I really do not want to take part in this fonts packaging business!

You're right that most packagers should not have to bother about font problems. And, actually, they don't! Any application that uses fontconfig will discover automatically where the fonts its author wanted are on system, and fallback transparently without crashes or breakage to other fonts if they're not present. Our fontconfig-aware packages do not need to bundle font files, symlinks, or dependencies on font packages.

If your upstream bundles specific font files, it is not using fontconfig. This will be a problem for you as fontconfig is the main *nix font system and the only one Fedora does heavy QA on. Alternatives are very prone to failure, each one of which will result in a bug open against your package.

Save yourself some work and convince your upstream to use fontconfig instead of other font discovery methods. And since fontconfig is a low-level library, upstream will usually want to use it through a higher-level library such as pangocairo.

Is there a simpler way?

See here.

I activated fontconfig in my application, should I remove font package dependencies? That feels unsafe!

You do not need any special font package dependency or symlink in a fontconfig-aware application. fontconfig is a very resilient system and will only fail if there is no font at all on-system that provides the glyphs needed to render your text. And in that case it will just not display text instead of crashing. Besides the fonts comps group is part of the default Fedora base install and should provide enough fonts to display most world scripts.

However, if your application has a preference for the style or metrics of a particular font, you can add a dependency on it to make sure it is installed and fontconfig does not have to fall back on another font.

But what if the fonts needed by a script are not installed?

Then Fedora will prompt users to install them. No need to add a specific dependency to your package.

The fontconfig stuff the font guidelines suggest seems complex. Can I avoid it?

There are good and simple commented fontconfig templates in the fontpackages-devel package. They only require you to fill in your font name and its category (so fontconfig and CSS aliases just work). So adding a fontconfig file should really be trivial (don't forget to send it to the font usptream for inclusion afterwards). We also have a wiki documentation page on the subject.

Nevertheless, this part is optional in the guidelines, to take into account the fonts which are already configured in the upstream fontconfig ruleset.

Can I just put all my fonts in a -fonts subpackage?

No, our actual requirements are deeper than that. Just moving font files in a separate subpackage, without making this subpackage comply with guidelines, is useless.

How should I name my fonts (sub)package(s)?

See requirements.

But my package has always worked this way!

Fedora fonts handling has long-standing problems but is slowly getting fixed. Please contribute to this fixing by bringing your package into line.

But other distributions do not bother!

Fedora is not other distributions. It is intended to lead[…] the advancement of free, open software and content[6].

This is too much work!

The amount of work necessary to make a package conform to our font guidelines is usually proportional to the amount of problems in a particular package, so if there is a lot of work to do that indicates a problem package we should really not ship in its current state.

Getting new font packages reviewed is going to take ages!

Packages that follow our packaging process get reviewed by a dedicated team in days, and will get merged just as fast if the submitter is responsive to the review comments.

The %_font_pkg is forcing choices on me!

This is the intent. We added this macro to purge all the custom font scriptlets in the distribution, since the variations packagers introduced almost invariably produced unforeseen bugs.

Where is the rest of the subpackaging bits in spectemplate-fonts-multi.spec?

The %_font_pkg macro is taking care of this for you.

What happened to the fc-cache scriptlets listed in previous guidelines?

The %_font_pkg macro is taking care of this for you.

Where are the %files sections of my font (sub)packages?

The %_font_pkg macro has an integrated %files section. It starts in the macro itself and continues till the beginning of the next rpm section. You can add additional content to a (sub)package created with %_font_pkg by listing it after the %_font_pkg call line[7].

rpmbuild complains of font files being listed twice!

You probably listed the font files in a manual %files section instead of letting %_font_pkg take care of them for you. Read this.

rpmbuild fails with Package does not exist: %post fonts[-…]-fonts

You've been bitten by this change. The fix is documented here.

The templates must be wrong, rpmbuild crashes/fails!

It is unfortunately rather easy to make rpm crash when using macros. The documented syntax works and has been tested on dozens of packages. Trying to change it, however, will likely lead you to rpm crash land.

Try to not deviate from the documented syntax[8]:

  • for new packages, make sure you've added all the elements required in the templates.
  • when adaptating existing packages, make sure you've removed all the old %files %post %postun etc parts that may conflict with the new templates.
  • in all cases, check you've not cut and pasted the same subpackage name twice. rpm really does not like that

I have unowned directories!

You should not. If you follow our guidelines carefully, the font (sub)packages should own their font directory (if there is a single font family in the srpm) or depend on a common subpackage that owns it (if there are several font families in the srpm, resulting in multiple font packages).

If I make my font subpackage noarch koji crashes!

Don't do that. Our infrastructure is getting fixed to support this case, but can not handle it (yet).

rpmlint complains of absolute symbolic links!

The future of this particular warning is being discussed by FPC right now (ideally rpmbuild should convert absolute symlinks to relative ones transparently). You can ignore it for now.

No font (sub)package is created in mock/koji!

You've forgotten to include the template (build)requires on fontpackages-*.

How about console/X11 core fonts/TEX/ghostscript fonts packaging or registration?

No one cared enough about those so far to write corresponding Fedora packaging guidelines[9]. You are free to add whatever you want about them to your packages, as long as it's not in the guidelines-compliant font (sub)package.

To add the overlay corresponding to another font system to a Fedora fonts (sub)package, create a separate (sub)package that contains this overlay and depends on the corresponding fonts guidelines-compliant (sub)packages (and not the reverse)[10].

Fedora fonts are broken anyway, my application crashes!

A crashing application is a symptom of an application not converted to fontconfig yet. Save yourself some grief and have your upstream/ISV convert it to fontconfig now.

Since the vast majority of our applications started using fontconfig quite long time ago, Fedora does not install the complete legacy X11 core fonts set by default anymore. If your application or package depends on it it has to request the associated packages explicitly[11].

Why all naming churn, font packages got renamed twice?

FPC unexpectedly refused to approve a proposal that put into writing the package naming rules for fonts we had been using in the past years[12]. Those rules were implied by packaging macros and templates FESCO and FPC had previously approved.

The revised naming rules [adopted] after taking into account the changes requested by FPC required renaming of several font packages, including recently created ones.

Why were provides for the old package names not added during naming changes?

The historic density of font package dependencies in Fedora is small and the changes were announced at the beginning of the Fedora 11 cycle so we feel it is quite possible and desirable to do a clean break and not carry on indefinitely old provides in the repository metadata.

This is even more true for transient package names that only existed a few weeks before FPC made us rename them.

As an exception the default Fedora font set, DejaVu, will carry provides for its old names till just before Fedora 11 beta, to give people time to adapt. Packagers who followed published advice have therefore a few weeks to transition.

Why did the %_font_pkg macro behaviour change after fontpackages version 1.13 ?

See here.

Why did the multi-fonts-families template change after fontpackages version 1.13 ?

See here.

What font packaging changes are needed with post-1.13 fontpackages ?

Fonts packaging changes required by the new FPC packages naming rules for fonts
Case Example, for the foo fonts family
Old template New template
Single-fonts-family fonts packages No changes
Multi-fonts-families fonts packages
%package foo

%description foo
%package -n %{fontname}-foo-fonts
Obsoletes: %{name}-foo < thisversion-thisrelease

%description -n %{fontname}-foo-fonts
Fonts subpackages of non-font source packages
%package fonts-foo
%description fonts-foo
%_font_pkg -n fonts-foo …
%package foo-fonts
%description foo-fonts
%_font_pkg -n foo  …

I have other questions/who can help me?

If this page does not answer all your questions you can always ask for help on the Fedora fonts mailing list.


  1. .pfa or .pfb Type1 fonts may have other companion files.
  2. At this time Fedora 9 and 10.
  3. Simple, but sadly not available in each and every Fedora release.
  4. Type <CTRL> + <SHIFT> + <F> to open the font metadata window in fontforge.
  5. CTRL + SHIFT + F, then look at Names, TTF Names, etc.
  6. Though Debian for example started auditing its fonts in 2005, so we have to do some catching-up first.
  7. This is how the basic template handles %doc and ownership of the font directory
  8. Package reviewers will thank you, especially if a visual diff between your spec and the official template is minimalistic.
  9. Volunteers would be very welcome!
  10. For example, since the fonts guidelines will put all the fonts provided by the same srpm in the same directory, and core fonts only allow one fonts.scale index per directory, you can not have a core fonts overlay per subpackage, but only one per srpm.
  11. Via package dependencies for Fedora packages, or in whatever it uses as installation procedure for third-party software.
  12. For example, by the Stix fonts package.

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.