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
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 at laposte.net> 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
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 usersThen 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 packagesFor 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
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080723/aecac48d/attachment.pgp
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
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080723/a0ec0c11/attachment-0001.pgp
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=16818Thanks! -- Nicolas Mailhot Still looking for the pony fairy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080723/62cacd5b/attachment.pgp
>>>>> "Nicolas" == Nicolas Mailhot <nicolas.mailhot at laposte.net> 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 at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Le Mer 23 juillet 2008 21:45, James Cloos a ?crit :> >>>>>> "Nicolas" == Nicolas Mailhot <nicolas.mailhot at laposte.net> >>>>>> 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 > availableNicolas> 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
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
mpsuzuki at hiroshima-u.ac.jp
2008-Jul-25 05:06 UTC
[Fontconfig] TTF/OTF packaging thoughts?
Hi, I''m sorry to ask an off-topic question in this list. On Wed, 23 Jul 2008 13:49:58 -0400 Behdad Esfahbod <behdad at behdad.org> wrote:>On Wed, 2008-07-23 at 19:28 +0200, Nicolas Mailhot wrote: >> Le mercredi 23 juillet 2008 $(D+"(B 11:51 -0400, Behdad Esfahbod a $(D+1(Bcrit : >> > 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.According to the descriptions of existing implementations in OpenType spec, TTC-packed CFF OpenType seems to be dealt as too-new file format. So, a TTC including TrueType and CFF OpenType is, furthermore, too-new and exotic. One of the advantage to pack multiple TrueType into TTC is: sharing same loca/glyf/EBLC/EBDT but different cmap/post is easy to make a compact font file when most glyphs are shared but a small group of glyphs are different (e.g. fixed-width CJK font and proportional CJK font). This advantage is not so significant in CFF OpenType. Using same CFF table for such purpose is difficult, because CFF table has its own font family names, and assigns the unique glyph names to all glyphs. It would be expected that the glyph names in CFF table are compatible with Adobe Glyph Names, so using separated CFF tables for each faces would be easier. In such case, the reduction of the font file size would not be so significant. I guess, the advantage of TTC-packed CFF OpenType is just the reduction of the number of font files. It''s something like "cff_fonts.tar". 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. If I''m missing some points, please let me know. Regards, mpsuzuki
On Fri, 2008-07-25 at 14:06 +0900, mpsuzuki at hiroshima-u.ac.jp 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
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080725/43a8a8ca/attachment.pgp
On Fri, 2008-07-25 at 10:20 -0400, Behdad Esfahbod wrote:> On Fri, 2008-07-25 at 14:06 +0900, mpsuzuki at hiroshima-u.ac.jp 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.I think a TTC of TT+CFF is going to be seriously evil. But I won''t stand in the way of the courageous fool that will try to inject one in the distribution. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20080725/16c749f8/attachment.pgp
Are you sure this is a valid TTC? I thought it can contain only TrueType fonts (possibly with OpenType features). On Fri, Jul 25, 2008 at 5:26 PM, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:> On Fri, 2008-07-25 at 10:20 -0400, Behdad Esfahbod wrote: >> On Fri, 2008-07-25 at 14:06 +0900, mpsuzuki at hiroshima-u.ac.jp 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. > > I think a TTC of TT+CFF is going to be seriously evil. But I won''t stand > in the way of the courageous fool that will try to inject one in the > distribution. > > -- > Nicolas Mailhot > > _______________________________________________ > Fedora-fonts-list mailing list > Fedora-fonts-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-fonts-list > >