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-wide fonts audit and repackaging.

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, .pfb or pcf 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 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.

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.

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 and this other question.

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

Use this information to check if the font is already packaged, and if not what the actual font upstream is and if it is suitable for packaging (web search engines are your friends).

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.

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

Adding a good fontconfig ruleset to your package will greatly enhance your users' experience.

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

Which fontconfig number prefixes are safe for me to use?

It is almost always safe to use high numbers in the prefix range your font belongs to.

Can I use font filenames in my fontconfig rules?

No, use font family names.

What fontconfig generic family should I put my font in?

The CSS classification system currently used by fontconfig is the following:

1. a font that can not be used to write long “professional” texts is a fantasy font.
2. otherwise:
   1. if it's monospaced, it's a monospace font,
   2. if it's variable-width and:
      1. it simulates hand-written text, it's a cursive font,
      2. it uses serifs, it's a serif font,
      3. it does not use serifs, it's a sans-serif font,
   3. otherwise, are you really sure it's not a fantasy font?

Some font authors also make their fonts self-categorize, thus checking the font metadata in fontforge may provide another hint. However, sometimes this metadata is missing or plain false, so do not rely on it 100%.

Where can I find more fontconfig information?

See here.

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.

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!

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

How can I get a new font package included in Fedora/OLPC/EPEL?

Just follow the process outlined here.

Can I re-indent/re-order the fonts packaging template?

You are of course free to re-indent the font packaging templates, change the spec metadata declaration order, and remove or add empty spacing lines.

However, consider that it will always be easier for you and reviewers to check there is no mistake if a graphical diff tool highlights only minimal changes. Also we do improve the templates with time, and formatting changes will make it harder for you to keep up with them later.

The %_font_pkg macro 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.

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:

• 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

Building from sources? But fonts can't have sources!

See Legal considerations for fonts#font-sources.

Upstream provides font sources in sfd format, how can I build them?

Our guidelines mandate building from source whenever possible, and this is often a licensing requirement.

If your upstream didn't include a nice Makefile:

• take inspiration from the Inconsolata package.
• DejaVu, Liberation, Edrip, Heuristica all include examples of complete upstream-provided Makefiles.
• lastly, please consider writing one for your upstream and having it included in its archive releases.

What font format should I target?

Please try to convince your upstreams to publish fonts in OpenType Unicode format (TTF/.ttf or CFF/.otf, it does not matter for us).

See also Choosing the right font format to package.

Can I create noarch subpackages?

Yes, you can and should create noarch subpackages if you main package is not noarch. However, that only works for Fedora 11 and later. For earlier releases, your subpackage can not have a different buildarch than your main package.

rpmlint complains of absolute symbolic links!

Fedora does not care about the nature of a symlink. Ignore this warning.

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. 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 it it has to request the associated packages explicitly.

Do I need to Obsolete my old package names?

See Upgrade paths — renaming or splitting packages.

But my old package is replaced by several new packages!

See Upgrade paths — renaming or splitting packages.

Can't I use my old package name instead of a -compat subpackage?

See Upgrade paths — renaming or splitting packages.

Do I need to Provide my old package names?

See Upgrade paths — renaming or splitting packages.

What if the new naming guidelines require me to rename my source package?

See Upgrade paths — renaming or splitting packages.

How can I check if my upgrade path work?

See Upgrade paths — renaming or splitting packages.

Am I done after creating a new fonts (sub)package or renaming an existing one?

Almost. You also need to trace your font package additions or changes in Fedora 11 comps.

Why is the common subpackage in the multi-font-families templates named foo-fonts-common and not foo-common-fonts?

This subpackage is a normal utility subpackage with no fonts inside so there's no reason not to name it srpmname-common as usual (it's not a font package with a font family named Common inside).

What's the point of the common subpackage?

It's here to own files common to all the fonts subpackages (documentation…), and manage their common dependencies (such as fontpackages-filesystem.

How can I help test and QA the fonts packaging changes?

See Features/Repackaging_of_Fedora_fonts#How_To_Test.

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.