Shipping fonts in Fedora (FAQ)

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 fonts 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. Should it happen 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.

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

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

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 named according to our naming guidelines for fonts.

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

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 dependencies do 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 them and tracing their sources 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'
dejavu-fonts-sans-mono-0:2.28-1.fc11.noarch

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.

What if my package bundles Bistream Vera, Arev, DejaVu LGC or another Vera 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 Bistream 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 won't 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 font 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?

Assuming your application needs all those different formats, and you can not consolidate the files, 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 can I decide which fonts belong in the same package or subpackage?

See this draft.

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.

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 introduced unforeseen bugs.

I have unowned directories!

You should not. If your 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 symlinks

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.

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

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 them it has to request them explicitely.

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.

Notes:

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.