TTF/OTF packaging thoughts?

[Nicolas Mailhot]

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

[Nicolas Mailhot]

Le Mer 23 juillet 2008 12:23, Vasile Gaburici a écrit :
>  I'll share my thoughts in more detail later -- I'm in a hurry now.
>  One bit I was going to say:
>
>  On Wed, Jul 23, 2008 at 11:53 AM, Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
> > 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.
>
>  Probably not. Linux Libertine's own packaging has an "O" appended to
>  the OpenType CFF version(s), e.g.
>  "Linux Libertine O" is CFF. This kinda' sucks. We need a more elegant
>  solution... 
If projects like Linux Libertine and Old standards systematically use
different font names for OTF and TTF versions, we can avoid the "make
the two subpackages conflict" bit, and just have two subpackages, that
each declare themselves as valid substitute for the other

(ie Linux Libertine O package says "you can use me instead of Linux
Libertine if it's not present on system and Linux Libertine says "you
can use me instead of Linux Libertine O if it's not present on
system")

-- 
Nicolas Mailhot

[Jon Stanley]

On Wed, Jul 23, 2008 at 4:53 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; 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.

[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

[Vasile Gaburici]

On Wed, Jul 23, 2008 at 8:59 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  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. 
Indeed. I was one that believed there would be a difference, but even
at 512 display size, I don't see a single pixel that differs.
Screenshots here:
https://bugzilla.redhat.com/attachment.cgi?id=312489
https://bugzilla.redhat.com/attachment.cgi?id=312491

On the other hand, CFF and TFF use different hinting mechanisms, and
there a visible difference at small (10-12) point sizes, even on
Windows.

On the TTF vs. CFF issue, Adam Twardoch, one of the FontLab's managers
(don't let this make you think he's all marketingspeak) has some
insightful comments here:
http://www.typophile.com/node/16695#comment-99516. My summary of his
position is that TrueType in in OpenType packaging should genrally be
prefered to OpenType/CCF as an end-user delivery method, all other
features being equal.

Unfortunately, on Fedora we also have a more complex hinting issue:
Apple has a patent on TrueType hinting, so TT hinting is off by
default (there's a Livna package to enable it). Also, most free fonts
like Linux Libertine store the manually produced PostScript hinting in
their sfd file (I checked with Philipp), and the TT hinting is
generated in FontForge just before the TTF is exported. So my guess is
that the CFF hinting is likely to be better, since it's hand-made. I
need to do a few more test on this though...

[Gustavo Ferreira]

On Jul 23, 2008, at 2:59 PM, Nicolas Mailhot wrote:

>  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) 
screen optimisation strategy is another significant difference  
between the two formats.

truetype fonts contain instructions, active information which tells  
the rasterizer exactly how each pixel should be drawn on screen at a  
given ppem size. postscript/opentype cff fonts contain hints, passive  
information which is interpreted by the rasterizer.

maybe this difference is not significant under linux/free type, but  
it is huge for windows users.

[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

[Nicolas Mailhot]

Le mercredi 23 juillet 2008 à 11:51 -0400, Behdad Esfahbod a écrit :
>  On Wed, 2008-07-23 at 10:53 +0200, Nicolas Mailhot wrote: 
>  > 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. 
>  It uses the version number to prefer one over the other.  If both
> have
>  the same version, it may not be deterministic, not sure. 
That's unfortunately the case we're likely to have.

>  > 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. 
I agree if OTF = OpenType (CCF or not)

>  > 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? 
In my mail OTF = OpenType CCF, TTF = OpenType TTF

OO.o does not support the first one at all.
http://qa.openoffice.org/issues/show_bug.cgi?id=78858
http://qa.openoffice.org/issues/show_bug.cgi?id=43029

It supports the second one badly.
http://qa.openoffice.org/issues/show_bug.cgi?id=78749
http://qa.openoffice.org/issues/show_bug.cgi?id=16032
http://qa.openoffice.org/issues/show_bug.cgi?id=79878

Maybe if you complain to the OO.o guys they'll start to do something
about it. They've certainly not exhibited a lot of enthusiasm so far.

This is a major problem given almost all the fonts we've recently
included or plan to include are OpenType CCF.

>  > 5. But not shipping them will annoy other classes of users (TEX
> users,
>  > etc)
>  
>  "TrueType OTF" makes everyone happy, doesn't it? 
We have at least one TEX user firmly believing in the superiority of
cubic splines (not surprising after the years of Adobe marketing on the
subject) asking to provide a OpenType CCF version of a font we already
ship as OpenType TrueType (and can't drop till the OO.o bugs are fixed)

>  > 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. 
I really do not like it either. But I don't see how to keep both TTF and
OTF users happy otherwise.

-- 
Nicolas Mailhot

[Behdad Esfahbod]

On Wed, 2008-07-23 at 19:28 +0200, Nicolas Mailhot wrote:
>  Le mercredi 23 juillet 2008 à 11:51 -0400, Behdad Esfahbod a écrit :
>  > On Wed, 2008-07-23 at 10:53 +0200, Nicolas Mailhot wrote:
>  
>  > > 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.
>  
>  > It uses the version number to prefer one over the other.  If both have
>  > the same version, it may not be deterministic, not sure.
>  
>  That's unfortunately the case we're likely to have. 
Right.  Too bad the OpenType spec does not allow having both CFF and
TrueType outlines in one container.


>  > > 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.
>  
>  I agree if OTF = OpenType (CCF or not) 
Right.  I keep forgetting that MS calls it otherwise.


>  > > 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?
>  
>  In my mail OTF = OpenType CCF, TTF = OpenType TTF
>  
>  OO.o does not support the first one at all.
>  http://qa.openoffice.org/issues/show_bug.cgi?id=78858
>  http://qa.openoffice.org/issues/show_bug.cgi?id=43029
>  
>  It supports the second one badly.
>  http://qa.openoffice.org/issues/show_bug.cgi?id=78749
>  http://qa.openoffice.org/issues/show_bug.cgi?id=16032
>  http://qa.openoffice.org/issues/show_bug.cgi?id=79878
>  
>  Maybe if you complain to the OO.o guys they'll start to do something
>  about it. They've certainly not exhibited a lot of enthusiasm so far. 
Yeah, lets do that.  It's much more promising now that they are porting
to cairo.  Unfortunately I don't think they port their printing code any
time soon, but when they do, all fonts will be supported.  (It just
happens that cairo is so lucky to have someone called Adrian Johnson who
implements support for all and every font types in the PDF backend...
Makes all other projects envious)


>  This is a major problem given almost all the fonts we've
> recently
>  included or plan to include are OpenType CCF.
>  
>  > > 5. But not shipping them will annoy other classes of users (TEX users,
>  > > etc)
>  > 
>  > "TrueType OTF" makes everyone happy, doesn't it?
>  
>  We have at least one TEX user firmly believing in the superiority of
>  cubic splines (not surprising after the years of Adobe marketing on the
>  subject) asking to provide a OpenType CCF version of a font we already
>  ship as OpenType TrueType (and can't drop till the OO.o bugs are fixed)
>  
>  > > 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.
>  
>  I really do not like it either. But I don't see how to keep both TTF and
>  OTF users happy otherwise. 
If we want to install both, just put them side by side I guess with no
split packaging, and lets patch fontconfig if needed, to make it decide
deterministically.

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

[Nicolas Mailhot]

Le mercredi 23 juillet 2008 à 13:49 -0400, Behdad Esfahbod a écrit :

>  > > > 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?
>  > 
>  > In my mail OTF = OpenType CCF, TTF = OpenType TTF
>  > 
>  > OO.o does not support the first one at all.
>  > http://qa.openoffice.org/issues/show_bug.cgi?id=78858
>  > http://qa.openoffice.org/issues/show_bug.cgi?id=43029
>  > 
>  > It supports the second one badly.
>  > http://qa.openoffice.org/issues/show_bug.cgi?id=78749
>  > http://qa.openoffice.org/issues/show_bug.cgi?id=16032
>  > http://qa.openoffice.org/issues/show_bug.cgi?id=79878
>  > 
>  > Maybe if you complain to the OO.o guys they'll start to do something
>  > about it. They've certainly not exhibited a lot of enthusiasm so far.
>  
>  Yeah, lets do that.  It's much more promising now that they are porting
>  to cairo. Unfortunately I don't think they port their printing code any
>  time soon, but when they do, all fonts will be supported.  (It just
>  happens that cairo is so lucky to have someone called Adrian Johnson who
>  implements support for all and every font types in the PDF backend...
>  Makes all other projects envious) 
I fear the cairo port is at least a year away
http://qa.openoffice.org/issues/show_bug.cgi?id=88613
So it's not a solution to our next releases

>  > I really do not like it either. But I don't see how to keep
> both TTF and
>  > OTF users happy otherwise.
>  
>  If we want to install both, just put them side by side I guess with no
>  split packaging, and lets patch fontconfig if needed, to make it decide
>  deterministically. 
Can you patch fontconfig so apps get OTF (OpenType CFF) versions by
default, unless they explicitely request OpenType TTF files? (when the
same version of the same font is available in both formats)

That would simplify the problem to just having OO.o use the second mode
till it fixes its bugs (plus probably just hide any CFF font to apps
using the second mode)

I must admit my main motivation for split packaging was avoiding the QA
hell of some users getting TTF in OO.o, others getting OTF, having OO.o
fail, and open bug reports.

-- 
Nicolas Mailhot

[Fontconfig] TTF/OTF packaging thoughts?

[James Cloos]

> >>>> "Nicolas" == Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net&gt; writes: 
Nicolas> Can you patch fontconfig so apps get OTF (OpenType CFF)
Nicolas> versions by default, unless they explicitely request OpenType
Nicolas> TTF files? (when the same version of the same font is available
Nicolas> in both formats)

You may be able to do that in fonts.conf.

test name="fontformat" for the strings >TrueType<, >CFF< or >Type
1<.

Or, you might want to patch apps like OO.o, AbiWord, et al to ignore
CFF; there is a C-level api for that, too.  In fact, until they actually
support CFF, they should do that upstream....

-JimC
-- 
James Cloos <cloos(a)jhcloos.com&gt;         OpenPGP: 1024D/ED7DAEA6

[Fontconfig] TTF/OTF packaging thoughts?

[Nicolas Mailhot]

Le Mer 23 juillet 2008 21:45, James Cloos a écrit :
> >>>>> "Nicolas" == Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net&gt;
> >>>>> writes:
>
>  Nicolas> Can you patch fontconfig so apps get OTF (OpenType CFF)
>  Nicolas> versions by default, unless they explicitely request OpenType
>  Nicolas> TTF files? (when the same version of the same font is
>  available 
Nicolas> in both formats)
>  You may be able to do that in fonts.conf.
>  test name="fontformat" for the strings >TrueType<, >CFF< or
> >Type 1<. 
But is it possible to write a blanket rule for all fonts?

>  Or, you might want to patch apps like OO.o, AbiWord, et al to ignore
>  CFF; there is a C-level api for that, too.  In fact, until they
>  actually support CFF, they should do that upstream.... 
Ok, I guess that means we need to open app-specific bugs now.

-- 
Nicolas Mailhot