Re: [Fontconfig] TTF/OTF packaging thoughts?
On Fri, 2008-07-25 at 14:06 +0900, [EMAIL PROTECTED] wrote: What is the advantage to pack TrueType and CFF OpenType? I guess, the shareable contents are limited as TTC-packed CFF OpenType, so, such request comes from the people looking for an easy archiver of font files. Yes, I was just meaning having one file for a face. -- 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 ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
On Thu, 2008-07-24 at 10:31 +0200, Nicolas Mailhot wrote: All, After the discussion on two public lists, and some public and private exchanges on IRC with people whose opinion I respect a lot, since no one proposed a problem-free way to do dual format packaging, and many objected to all this complexity just to work around OpenOffice.org bugs, I propose the following simplified policy. […] Is everyone happy with this? If you have a convincing argument to do something else please speak up now. Otherwise I'll add these rules to the wiki before the end of the week (and the start of my vacations), Done here: http://fedoraproject.org/wiki/Choosing_the_right_font_format_to_package -- Nicolas Mailhot signature.asc Description: This is a digitally signed message part ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [Fontconfig] TTF/OTF packaging thoughts?
Le Mer 23 juillet 2008 21:45, James Cloos a écrit : Nicolas == Nicolas Mailhot [EMAIL PROTECTED] 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 ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Fwd: TTF/OTF packaging thoughts?
-- Forwarded message -- From: Vasile Gaburici [EMAIL PROTECTED] Date: Thu, Jul 24, 2008 at 11:51 AM Subject: Re: TTF/OTF packaging thoughts? To: Nicolas Mailhot [EMAIL PROTECTED] I agree with all your points. Regarding point 7, I'm going to emphasize, as you did previously, that conversion from Type 1 to OpenType/CFF is a non-trivial job, as the recent thread on the OpenType versions of the URW fonts has shown. So, until someone finds the significant time required to do a proper conversion, we should try to make the type-1 fonts that Fedora does ship as usable as possible *in Fedora*. Currently I can use the URW Type 1 fonts that Fedora ships for [Unicode 3.0+ encoded] Romanian *in Windows*, but not in Fedora. I'm still investigating the best way to emulate Uniscribe's solution. The issue that URW's fonts have is shared by most commercial Type 1 fonts as well. Even if Fedora doesn't ship any of those, it would not hurt to have them work in Fedora since they require the same hack that URW fonts do. On Thu, Jul 24, 2008 at 11:31 AM, Nicolas Mailhot [EMAIL PROTECTED] wrote: All, After the discussion on two public lists, and some public and private exchanges on IRC with people whose opinion I respect a lot, since no one proposed a problem-free way to do dual format packaging, and many objected to all this complexity just to work around OpenOffice.org bugs, I propose the following simplified policy. 1. If upstream works with one preferred OpenType format (TTF or OTF), use this format. 2. If a font is available in both TTF (OpenType TT) and OTF (OpenType CCF) formats, package the most recent and complete version. 3. If both formats are generated from the same source upstream, package the OTF (OpenType CCF) version. The reason is most font editors work with cubic splines natively, and we don't ignore CFF hinting the way we do TT hinting (different legal context), so the OTF version may be slightly better in our context. 4. For already packaged fonts, continue to package the TTF (OpenType TT) format till OO.o is fixed. The reason is to avoid upsetting users that already created documents using the TTF version, that won't work anymore if we switch to OTF under their feet. After OO.o is fixed apply the same policy as for new packages. 5. As an exception, a maintainer is allowed to use his best judgement and package both versions in a single rpm, if a user manages to convince him it's not a terribly bad idea. (but never do it by default). Bear in mind that in addition to the previously mentioned problems that will double the package size so livecd and bandwidth-constrained users won't be happy about it. But at least the packaging will be simple. 6. Since it seems several projects use different font names for the OTF and TTF variants, systematically package a fontconfig ruleset that maps the font name we do not package to the one we do. Is everyone happy with this? If you have a convincing argument to do something else please speak up now. Otherwise I'll add these rules to the wiki before the end of the week (and the start of my vacations), and probably send them FPC/FESCO side so they can be officialized. Also I propose: 7. Do not package new Type1 fonts. If someone cares about a Type1 font, he should get it converted to OpenType CFF before we consider packaging it. (though it seems Type1 is moribund enough no one has proposed new Type1 fonts in ages) Regards, -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
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 ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
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 [EMAIL PROTECTED] 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 ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
On Wed, Jul 23, 2008 at 4:53 AM, Nicolas Mailhot
[EMAIL PROTECTED] 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.
___
Fedora-fonts-list mailing list
Fedora-fonts-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
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 ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
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 signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
Le mercredi 23 juillet 2008 à 14:36 -0400, Behdad Esfahbod a écrit : On Wed, 2008-07-23 at 20:14 +0200, Nicolas Mailhot wrote: 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) Not right now. But filed it at least: https://bugs.freedesktop.org/show_bug.cgi?id=16818 Thanks! -- Nicolas Mailhot Still looking for the pony fairy signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: TTF/OTF packaging thoughts?
On Wed, Jul 23, 2008 at 8:59 PM, Nicolas Mailhot [EMAIL PROTECTED] 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... ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
