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

TTF/OTF packaging thoughts?



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.

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

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

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

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

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?

-- 
Nicolas Mailhot


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