TTF/OTF packaging thoughts?

[Behdad Esfahbod]

On Wed, 2008-07-23 at 10:53 +0200, Nicolas Mailhot 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)
> 
> 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.

It uses the version number to prefer one over the other.  If both have
the same version, it may not be deterministic, not sure.


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

No, right solution is OTF for all.

> 4. Unfortunately, Java and OO.o have lots of problems with OpenType
> CFF fonts
> http://fedoraproject.org/wiki/Known_fonts_and_text_bugs
> (please comment and vote on the relevant issues to put some pressure
> on upstream)
> So shipping only OTF versions is likely not to go well with OO.o users

Then lets fix OO.o and Java (we have a Free java now).  Don't hold back
the OTF transition.  There's a reason that OTF is backward compatible.
Or do you mean "OpenType CFF" when you say OTF?


> 5. But not shipping them will annoy other classes of users (TEX users,
> etc)

"TrueType OTF" makes everyone happy, doesn't it?


> 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
> obviously more complete (more recent version with more fixes or
> coverage), in which case we only package this version without
> subpackaging.
> - 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

For god's sake no.  Keep it simple.

> 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.
> 
> Thoughts?
> 
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759