TTF/OTF packaging thoughts?

[Jon Stanley]

On Wed, Jul 23, 2008 at 4:53 AM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Hi all,
>
> We have several issues posing the problem of dual OTF/TTF fonts
> packaging.
> http://bugzilla.redhat.com/show_bug.cgi?id=456345
> http://bugzilla.redhat.com/show_bug.cgi?id=455995
>
> Till now we've managed to avoid this issue, however it seems we can't
> escape Fedora guidelines on the subject anymore.
>
> Anyway, my feeling right now (I've not thought a lot on it) is:
>
> 1. the immense majority of apps do not access font files directly,
> they all use fontconfig (or should use fontconfig someday)

Agreed.

> 2. I don't know what algorithm fontconfig uses to choose between
> several formats of the same fonts, or even if its choices are stable.
> But whatever it is I think apps will only see one version of the fonts
> (or even one format for a face and another for other faces). So
> installing two formats on-disk is likely to be a waste of bandwidth
> and storage, and a source of subtle application bugs.

Let's hope it's some deterministic algorithm - OTF is better than TTF,
for example.

> 3. That being said, the right solution would seem to be obvious. Just
> use TTF only for quadratic fonts, and OTF only for cubic fonts. Long
> term most fonts will probably be OTF only (given it's a little better
> than TTF for new fonts).

/me new to this whole fonts game - unsure of what's meant here :)


> 6. So I guess we probably need to do something like this:
> - fonts available in TTF and OTF formats have foo-fonts-ttf and
> foo-fonts-otf subpackages (no base package), unless one format is

There needs to be a base package per packaging guidelines, and the
reasoning makes sense here too. If we didn't have that, we'd have two
packages throwing things into %{fontdir} with no one owning it. So the
base package has to at least own that directory (and hence the
requirement for fully versioned Requires, etc). If upstream was nice,
and included a detached license file, font map, etc to include in
%doc, then those should go into the base package as well. I've also
left the fontconfig file in the base package since it applies to both.

I've done this in a generic way (that could perhaps be integrated into
the template?) for the font that started this discussion at
http://jstanley.fedorapeople.org/sportrop-fonts.spec

> obviously more complete (more recent version with more fixes or
> coverage), in which case we only package this version without
> subpackaging.

Yep

> - the ttf subpackage is only provided if the format is supported
> upstream (no conversion on our side if upstream does not QA it)
> - if the font was mono-format before, foo-fonts-ttf obsoletes all the
> foo-fonts packages till the last known version (but no later)
> - the two packages own their subdirs if they share them and conflict
> with each other
> - when has OO.o fixed its bugs, we make foo-fonts-otf the new
> foo-fonts package, obsoleting all previous foo-fonts-otf and
> foo-fonts-ttf packages

Is OO.o really the only reason to ship a TTF version? I'm thinking
that if upstream provides it, we should probably ship it (and make the
otf version the default once OO.o fixes it's bugs)

> 7. for projects that use different font names for both formats (but
> functionally equivalent, since they are created from the same sfds),
> change them for both fonts export the same family name (with
> fontconfig aliasing of the upstream name) and use the same rules as
> before. An example would be Old Standards.

This would be utter craziness - but oh well.