Purpose

This page is intended to define a common set of rules for package names, its content, and other related information.

How to Select a New Font

There are lots of "free" fonts out there which could theoretically be packaged. However, we should strive for quality, not quantity. Therefore, here are some guidelines you should answer first before you package a new font at all:

Is the font open source? You should focus on free fonts released under the OFL, GPL, or any other open or free source license. Although it should be clear, but commercial fonts MUST NOT be packaged at all!

Is the font already packaged? Before you package a new font, always look into M17N:fonts repository first. Search for similar package names.

How many font styles does the font bring with? Try to package fonts which have at least a regular and italic style. Preferably the font has also bold and italic+bold (that would make four styles). Sometimes, a font comes with small caps, other brings a condensed or wider variant, but this is not the usual case.

Can the font be used for different languages? Although you rarely will find a font which contains all possible languages, look for fonts which supports at least European languages. Some contains also Greek or Cyrillic glyphs. Others may support Asian characters. The more languages a font supports, the better will it be for the majority of users.

How many glyphs does the font have? This question is related to the previous one. However, there are more useful glyphs like arrows, dingbats, mathematical symbols, etc. Additional glyphs make it easier to use them for other purposes, like programming or specific texts.

Naming and Central Font Repository

Think of a good font name. The general syntax is this (all lower-case):

[foundryname-]projectname[-fontfamilyname][-fonttype]-fonts

Here is more detailed explanation

foundryname: Usually the name of the designer or a type foundry

projectname: the name of the font project

fontfamilyname: if the project contains different font families, specify it here

fonttype: subsitute 'bitmap' in case you package a bitmap font

In most cases, the package name is pretty short. For example, if you have a font project "foo", the package name will be "foo-fonts".

Almost all font packages are located in the M17N:fonts repository now.

Examples

How to Update an Existing Font Package

If you want to update a font to a newer version or you found a bug, the following procedure shows how to do it:

Open a shell and branch the existing font package on M17N:fonts:

osc bco M17N:fonts FONTPACKAGE

The osc script checks out the font package and saves it into home/USER/branches/M17N/fonts/FONTPACKAGE (if you have set checkout_no_colon=1 in your ~/.oscrc config file). This will be your current working directory.

Download the new package and save it into your working directory. Usually you can find the package from the project's homepage.

Change the version number in the spec file.

If needed, add patches or other requirements into the spec file (usually mostly not needed).

Write a meaningful changelog entry:

osc vc

(Probably you find information about the changes in the Changelog file if included into the archive, or on the project's homepage).

Your submission will be reviewed and if it conforms to our packaging rules it will be accepted. In case it is declined, you will be informed about the reason. Fix the errors or problems and submit it again (probably you may want to combine the -s option (superseding another request by this one) with your sr command).

Font Package with More Families

Many packages don't split into subpackages even if it contains more font families. Nevertheless, when you want to give users the chance to choose which family from your package to install, then you will have to split your font package in subpackages.

As a general rule of thumb: split a font into several packages, if it's "big". For "big" there is no exact definition, but a font can be considered "big" if it contains more than one font families or has lots of files which lead to a monstrous file size.

Examples

Packaging Fontconfig Files along Font Package

It may happen that you want to package a fontconfig file along with your font files. There's no policy
that the fontconfig file should be part of fontconfig package itself, so you are encouraged to include
it in your font package. With one exception: mapping to generic names serif, sans-serif,
monospace, cursive and fantasy. Especially <default> alias: it is intended to help fontconfig to find similar
fonts to yours when yours are not installed, so packaging it along with your package will evidently not work.

The fontconfig file can be shipped inside upstream tarball or you can add it as package source.

There's no strict rules for the name of the fontconfig file except common ones for fontconfig files
(see /etc/fonts/conf.d/README). If you want to use the RPM macro %install_fontsconf, you have to ensure that the name
of the fontconfig file is identical to that one you want to have in /etc/fonts/conf.d.

In following spec file example,
we want to install /etc/fonts/conf.d/31-foo-fonts.conf, so the file name in package source is 31-foo-fonts.conf. If the
fontconfig file is part of the upstream tarball, you have to either rename it manually or don't use the %install_fontsconf RPM macro (i. e. install it manually).

BuildRequires Changes since 12.2 (bdftopcf,xmkmf,imake, mkfontdir)

Since openSUSE 12.2, X11:XOrg project split and changed some packages. The packages bdftopcf, imake (includes xmkmf), and mkfontdir are now split into separate subpackages. It's good for end users for a minimal system, but such changes now breaks the old automatic build requirement chain, and makes BuildRequires more complicated.

If your build fails in openSUSE 12.2 or Factory with error messages like

bdftopcf/xmkmf/mkfontdir: Command not found.

or

Imakefile.c:34:0: fatal error: Imake.tmpl: No such file or directory.

you need the tweaks in this section.

The common BuildRequires used to package fonts before:

BuildRequires: xorg-x11
BuildRequires: xorg-x11-devel

need to make some changes.

Explanations of the old BuildRequires

xorg-x11 provides /usr/bin/bdftopcf,and xorg-x11-devel is actually used to call in xorg-x11-utils-devel,which includes xmkmf, imake and mkfontdir. so xorg-x11 can't be ignored.