TTF/OTF packaging thoughts?

[Nicolas Mailhot]

Le mercredi 23 juillet 2008 à 08:26 -0400, Jon Stanley a écrit :
> On Wed, Jul 23, 2008 at 4:53 AM, Nicolas Mailhot

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

The only significant functionnal difference between OpenType CFF (OTF)
and OpenType TrueType (TTF) nowadays is that CFF allows cubic splines
(curves expressed with third-order equations as in a⋅x³ + b⋅y² + c) and
TTF only supports quadratic (b⋅y² + c)

It's an historic remnant of last century digital font format wars: Adobe
chose cubic for its Type1 print-oriented fonts, while Microsoft/Apple
simplified the math for their PC-oriented TrueType format.

In practice you can approximate cubic splines by just cutting cubic
segments in many quadratic ones, which font editors like fontforge do
automatically, and at the sizes text is typically rendered there's no
visible difference.

But after years of marketing on the subject some users are convinced
transformation to quadratic for fonts designed with cubic splines is a
quality loss.

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

1. They can both own it if they conflict so they're not installed
concurrently.

2. And even if they were installed concurrently, the main argument
against multiple ownership of the same directory is it may be set up
with different permissions by different packages, which is obviously not
the case if all those packages are built from the same srpm

3. plus you can just use different fonts subdirs if you care about this


>  So the
> base package has to at least own that directory (and hence the
> requirement for fully versioned Requires, etc)

Not really

> 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 don't think duplicating those in two subpackages is too bad. Certainly
less than dumping a third package with a few documentation files and an
empty dir in our repositories.

> 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

I'll look at this.
If we can agree on a position on OTF/TTF dual packaging, certainly we'll
have to revise guidelines accordingly.

> Is OO.o really the only reason to ship a TTF version? 

Practically — yes. All the other software either supports OTF just fine
through system libs like pango, or has marginal font use (Java), or is
itself totally marginal.

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

The main problem  is that if we choose to ship an OTF version of a font
also available in TTF, it needs to be in a separate package so users can
pass on it to make sure they only get the TTF version in OO.o (or
conversely just install the OTF one if they don't care about OO.o)

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

The whole thing is crazyness :(

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