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 [[fontpackages|fonts packaging guidelines change]] and answers most questions asked during the subsequent [[rhbug:477044|distribution font audit]].

+

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 [https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00007.html fonts packaging guidelines change] and answers most questions asked during the subsequent [[Features/Repackaging of Fedora fonts|distribution-wide fonts audit and repackaging]].

=== Is this page a Fedora guideline? ===

=== Is this page a Fedora guideline? ===

Line 9:

Line 9:

=== What is a font file? ===

=== 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<ref>''.pfa'' or ''.pfb'' Type1 fonts may have other companion files.</ref>.

+

For the purposes of this page a font file is a file using the ''.ttf'', ''otf'', ''.ttc'', ''.pfa'', ''.pfb'' or ''pcf'' extensions<ref>''.pfa'' or ''.pfb'' Type1 fonts may have other companion files.</ref>.

=== What does Fedora require of me? ===

=== What does Fedora require of me? ===

Line 24:

Line 24:

{{Anchor|requirements}}

{{Anchor|requirements}}

−

=== What is a compliant font (sub)package? ===

=== What is a compliant font (sub)package? ===

−

* A guidelines-compliant font (sub)package contains a [[PackagingDrafts/Font_package_splitting_rules_(2008-12-21)|single font family]], packed with the [[fontpackages|'''%_font_pkg''' rpm macro]], and no other material (except for eventual directory ownership and licensing or other documentation files).

+

* A [[Packaging:FontsPolicy|guidelines-compliant]] font (sub)package contains a [[Packaging:FontsPolicy#Package_layout_for_fonts|single font family]], packed with the [[Packaging:FontsPolicy#Technical_implementation|'''%_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 [[PackagingDrafts/Font package naming (2009-01-13)|naming guidelines for fonts]].

+

* It is named according to our [[Packaging:FontsPolicy#Naming|naming guidelines for fonts]].

−

* It is referenced in the appropriate [[Comps fonts rules|comps]] group.

+

* It is referenced in the appropriate [[Packaging:FontsPolicy#Grouping|comps]] group.

* It has a [[:Category:Fonts|page]] in the wiki we can reference in release notes. To create such a page use this [[Font description template|template]].

* It has a [[:Category:Fonts|page]] in the wiki we can reference in release notes. To create such a page use this [[Font description template|template]].

Line 44:

Line 43:

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|font family]]. If your srpm includes files associated to different font families, you need to create one subpackage per font family.

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|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 [[PackagingDrafts/Font_package_splitting_rules_(2008-12-21)|font package splitting guidelines]].

+

See also our official [[Packaging:FontsPolicy#Package_layout_for_fonts|font package splitting guidelines]] and [[#What_if_my_package_bundles_the_same_font_in_several_different_formats.3F|this other question]].

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 [[Fontconfig packaging tips|wiki documentation page]] on the subject.

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 [[Fontconfig packaging tips|wiki documentation page]] on the subject.

### it does not use [http://en.wikipedia.org/wiki/Serif serifs], it's a ''sans-serif'' font,

+

## 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<ref>'''<CTRL>''' + '''<SHIFT>''' + '''<F>''' then check the OS/2 tab.</ref>. However, sometimes this metadata is missing or plain false, so do not rely on it 100%.

+

+

=== Where can I find more fontconfig information? ===

+

+

See [[#fontconfig-rules|here]].

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

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

Line 175:

Line 204:

=== Getting new font packages reviewed is going to take ages! ===

=== Getting new font packages reviewed is going to take ages! ===

−

Packages that follow our packaging [[Font package lifecycle|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.

+

Packagers that follow our font packaging [[#lifecycle|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.

−

=== The '''%_font_pkg''' is forcing choices on me! ===

+

{{Anchor|lifecycle}}

+

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

+

+

Just follow the process outlined [[Font package lifecycle|here]].

+

+

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

+

+

You are of course free to re-indent the font packaging [[Packaging:FontsPolicy#Technical_implementation|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<ref>Such as '''meld'''.</ref> 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.

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.

Line 211:

Line 251:

* in all cases, check you've not cut and pasted the same subpackage name twice. rpm really does not like that

* 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! ===

+

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

−

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

Don't do that. Our infrastructure is getting [https://fedorahosted.org/koji/ticket/125 fixed] to support this case, but can not handle it (yet).

+

Our guidelines [[Packaging:FontsPolicy#Building_from_sources|mandate]] building from source whenever possible, and this is often a licensing requirement<ref>For all the fonts that use a GPL-derived license, for example.</ref>.

* 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! ===

=== rpmlint complains of absolute symbolic links! ===

−

The future of this particular warning is being [[PackagingDrafts/Absolute_symlinks_in_fonts_templates_(2009-01-02)|discussed]] by FPC right now (ideally rpmbuild should convert absolute symlinks to relative ones transparently). You can ignore it for now.

+

Fedora [[PackagingDrafts/Symlinks|does not care]] about the nature of a symlink. Ignore this warning.

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

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

Line 227:

Line 282:

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

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

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<ref>Via package dependencies for Fedora packages, or in whatever it uses as installation procedure for third-party software.</ref>.

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<ref>Via package dependencies for Fedora packages, or in whatever it uses as installation procedure for third-party software.</ref>.

−

{{Anchor|fpc_renaming}}

+

=== Do I need to ''Obsolete'' my old package names? ===

−

=== Why all naming churn, font packages got renamed twice? ===

+

−

[[FPC]] unexpectedly [[Packaging:Minutes/20090106|refused to approve]] a [[PackagingDrafts/Font package naming (2008-12-22)|proposal]] that put into writing the package naming rules for fonts we had been using in the past years<ref>For example, by the ''Stix'' fonts package.</ref>. Those rules were implied by packaging macros and templates FESCO and FPC had previously approved.

+

See [[Upgrade paths — renaming or splitting packages]].

−

The [[PackagingDrafts/Font package naming (2009-01-13)|revised naming rules]] [https://www.redhat.com/archives/fedora-packaging/2009-January/msg00084.html adopted] after taking into account the changes requested by FPC required [https://www.redhat.com/archives/fedora-packaging/2009-January/msg00095.html renaming] of several font packages, including recently created ones.

+

=== But my old package is replaced by several new packages! ===

−

=== Why were ''Provides'' for the old package names not added during naming changes? ===

+

See [[Upgrade paths — renaming or splitting packages]].

−

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.

+

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

−

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

+

See [[Upgrade paths — renaming or splitting packages]].

−

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

Almost. You also need to trace your font package additions or changes in Fedora 11 [[Packaging:FontsPolicy#Grouping|comps]].

−

%description foo

+

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

−

</pre>

+

−

|

+

−

<pre>

+

−

%package -n %{fontname}-foo-fonts

+

−

[…]

+

−

Obsoletes: %{name}-foo < thisversion-thisrelease

+

−

%description -n %{fontname}-foo-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).

−

</pre>

+

−

|-

+

=== What's the point of the ''common'' subpackage''? ===

−

|Fonts subpackages of non-font source packages

+

−

|

+

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

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.

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.

[edit] 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.

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.

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.

[edit] 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.

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

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

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

[edit] 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:

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.

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.

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

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

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.

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

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.

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[8] 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.

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

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[9].

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

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.

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.

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

[edit] 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[12]. 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)[13].

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[14].

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

↑Via package dependencies for Fedora packages, or in whatever it uses as installation procedure for third-party software.