[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New font packaging guidelines



Le lundi 22 décembre 2008 à 14:56 +0200, Sarantis Paskalis a écrit :
> On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:

Hi Sarantis,

> > As some of you may know, after more than a month of consultation,
> > feedback and tweaking new font packaging guidelines have been approved
> > by FESCO.

> Two of my packages are TeX fonts (tetex-font-kerkis and 
> tetex-font-cm-lgc), which contain .pfb files (postscript type 1 from 
> what I could find out).

We've known for quite a	while TEX had a problem with fonts installation
and licensing. However repoquery unearthed many non-font packages that
shipped fonts (not only TEX packages, and a lot more than I
expected :(), so I'm going to write a general answer if you permit.

1. The target font management stack on Fedora is fontconfig. It has
“near universal” support including emacs-side¹.

2. If your app is fontconfig-aware you just need to package the fonts it
needs as a normal guidelines-compliant font package. Fontconfig will
then locate them for your app no matter on how the font files are named
or renamed. 

3. If your app is not fontconfig-aware, you should politely remind your
upstream it has a problem.

4. If your app is not fontconfig-aware, and there is no solution
upstream in the short term, you still need to package the fonts using
the normal Fedora fonts packaging guidelines. And then either patch your
app to look for its fonts in the guidelines-compliant location or
package a set of symlinks pointing to this location.

5. The preferred way to package fonts is to locate their original font
upstream and package the original font release in a separate fonts-only
package.

6. However, for fonts that are bundled in a software package with no
other form of release, or fonts which have some additional non-standard
stuff bundled with them (such as TEX packages), I don't think anyone
will complain too loudly if you package them as subpackage(s) of your
main package. As long as the subpackage(s) are clean,
guidelines-compliant, and can be used by Fedora users without dragging
with them your app or TEX or other non-general-purpose stuff.

For example, for a “tex-foo” TEX package, you could have:

tex-foo-fonts-fontname1 (normal font subpackage #1)
tex-foo-fonts-fontname2 (normal font subpackage #2)
[…]
tex-foo-fonts-common    (common font subpackage that owns the fonts dirs
                         and the fonts-licensing files²)
tex-foo                 (main TEX package that depends on the
                         tex-foo-fonts packages, includes symlinks to
                         the font files in standard locations and
                         other TEX stuff)

The subpackaging logic is pretty much the same as in the
spectemplate-fonts-multi.spec template included in fontpackages-devel
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please note that the current guidelines say that font packagers:
“SHOULD package each font family separately, and avoid font collections
that mix fonts of different history, licensing, or origin”³

There is some wiggle room between SHOULD and MUST, and it has posed
problems in the past six months, so I've pushed the simpler
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)#New_wording
FPC-side yesterday.

I hope that answers all your questions.

¹ After a period of “‘utter luddites’ shock” to quote a well-known xorg
contributor
http://thread.gmane.org/gmane.comp.freedesktop.xorg/34322/focus=34334

² of course if you're shipping a single font family, that requires a
single font subpackage, there's no need to separate directory and
licensing handling in a -common subpackage. Just create a single
tex-foo-fonts-fontname in that case.

³
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

Sincerely,

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]