TeX Live fonts

Sun Sep 6 10:53:51 UTC 2009

Le vendredi 21 août 2009 à 14:46 +0200, Jindrich Novy a écrit :
> Hi Nicolas,

Hi Jindrich,

Sorry for the late answer, I was offline for some time [CC-ing the fonts
list, hopefully other people will complete this answer].

> I'm currently looking in a way how to package fonts in TeX Live so
> that other uses takes benefit of them. I have read the
> Packaging:FontsPolicy and have a few questions to you if you don't
> mind.
> 
> 1) which fonts particularly are appropriate to package?

The most wanted and useful fonts are TrueType (OpenType TTF, .ttf)
fonts, followed by OpenType (OpenType OTF, .otf) ones. .otf is probably
the major font format of this decade, but OO.o does not support it
properly yet (I see upstream closed the associated bugs those past days,
but the support will probably make it to Fedora only for F13).

For specific fonts the current wishlist is usually a good indicator of
what people are interested in 

http://fedoraproject.org/wiki/Category:Font_wishlist

The most wanted TEX font set is probably TEX Gyre, but also probably not
suitable for Fedora inclusion right now (GUST derived some GPL fonts
under its own license, refused to respect the GPL, then got URW to
re-release the origin files under a different license, which ignores the
modifications people had made under the GPL for years, and makes it all
a huge mess. Unless you can confirm TEX Gyre is under the GPL, or under
the new URW license, with the licensing of all intermediate
contributions taken care of, it's best to stay clear of it).

That being said we package fonts in every possible general-purpose (ie
not metatype), the rationale being it's better to have them where Behdad
can check them for bugs rather than having users add them manually and
find bugs in the field.

To avoid conflicts we try to package only one format for each font (the
most recent/complete version) though TEX-related apps have been known to
require the installation of several formats in parallel. In that case
the different format should be cleanly separated in different
subpackages so the average user does not have to install the megs of
redundant data only specific users are interested in.

Likewise, when a font consists of a mix of general-purpose TTF/OTF data,
and specific TEX files, we try to separate them. Existing Kerkis
packages are probably a good example of current best practice:

– ctan-kerkis-calligraphic-fonts.noarch : Kerkis Calligraphic Type1
fonts
— ctan-kerkis-sans-fonts.noarch : Kerkis sans Type1 fonts
— ctan-kerkis-serif-fonts.noarch : Kerkis serif Type1 fonts

— tex-kerkis.noarch: Kerkis Type1 fonts, TeX support files

— ctan-kerkis-fonts-common.noarch : Kerkis Type 1 fonts, common files

> 2) is the simple font packaging template enough for the TeX Live font
> packaging?

Unfortunately, no. I hoped years ago to package everything using it, but
reality disagreed, that's why there are two templates now.

Unfortunately (1), rpm dependencies can not express "this package
contains A with features 1 2 3 and B with features 2 4 5". They can only
say "this package contains A and 1 2 3". For the font auto-installer to
work, features need to be clearly associated with a font family, and
"this package contains A and B 1 2 3 4 5" is not usable. Our font
packagers need to clearly separate each font family in its own
(sub)package so there is not confusion between the features of different
font families in the dependency solver.

Unfortunately (2), differentiating font families is not trivial to
automate either. For many years there were little order and conventions
in the setting of the font family and font style fields. So many font
creators used dangerous constructs such as

[font family] [font style]

[awesomebobfonts] [I rock rabbit regular]
[awesomebobfonts] [baobab italic bold]

when those two files obviously belong to different font families and
should have been named

[awesomebobfonts I rock rabbit] [regular]
[bobfonts baobab]               [italic bold]

It got so bad that Microsoft now systematically starts by collating the
font family and style declared by the font file and then uses heuristics
to try to re-separate them sanely.

http://blogs.msdn.com/text/attachment/2249036.ashx

So nowadays we mostly triage font files manually, using the same rules
as Microsoft to determine what is part of the same font family.
Microsoft targets the CSS font model, which is IMHO a sane target to
have.

http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf

You have the exact rules in the Microsoft paper, they boil down to "a
font family is a set of files that differ only by width, weight or
slant". So for example "Bold" is an in-family attribute, but "Small
Caps" or "Shadow" indicate a different font family.

Also, since old font formats used many different files to support
different encodings, we consider that font files that represent the same
design over different encodings are all part of the same family.

So to sum up we split font packages over font family lines, not
encodings (as used to be done by xorg for example, but the tech moved
the other way). The only exception are ttc files. Those can include
different font families in a single file, and there's no sane way to
separate then today.

Since TEX is full of old files you'll probably find many fonts that do
not respect the WWS model or are broken in some other way. Do not
hesitate to report those upstream as part of the packaging.

> 3) Is it ok to name the font foundry like texlive-accfonts?

As you've seen we tend to name our packages [foundry]-[fontfamily]-fonts
(or [foundry]-[fontfamily]-[format]-fonts when a font is packaged in
multiple formats).

When TEX is not the upstream of a font, it's probably better to package
the upstream version outside TEX and make the TEX part depend on it (for
example, the GFS fonts).

For fonts released primarily within TEX, I guess any of tex- texlive-
ctan- will do as foundry prefix. Current packages mostly use ctan-, but
I the TEX community is better placed than me to decide what prefix is
most appropriate. (I'd be best to codify it in a Fedora packaging
guideline so the question is not asked again in a few months).

However you also have the case of font authors that release some fonts
within TEX and others elsewhere. (for example, ADF). In that case I
suppose users will be happier to get them all under the same foundry
prefix, and not some under texlive- and others under foundry-. So I
guess the rule should be “use foundry as prefix when it's clearly
identified, and a generic prefix like texlive- or ctan- otherwise”.

PS. do use -fonts as postfix for font packages, not -font or fonts. 

I'm sorry about all the exceptions and manual rules — it just reflects
the sorry lack of conventions in the libre font world right now.
Hopefully more clean distro packaging will drain the swamp over time.

> Good news are that TeX Live 2009 is now in question for Fedora so that
> we could make benefit of the new fonts present there :)

That's awesome news. I look forward to have something else to complain
about in font packaging reports :p

Best regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-fonts-list/attachments/20090906/dd82e6d2/attachment.sig>