[mpeg-OTspec] ISO/IEC 14496-22 Amendment for Font Collections

[Adam Twardoch (List)]

Ken, 

in that font, are any of the 28 name ID 6 strings identical to any of the 7 CFF.FontName strings?

Eg. for each of the 7 CFF.FontName strings, is there always one name table in which the ID 6 string is the same as the CFF.FontName string? While in other name tables, ID 6 strings are used that are not found in any of the CFF.FontName?

Or are all the CFF.FontName strings complete different from the name ID 6 strings?

A.

Sent from my mobile phone.

> On 03.04.2015, at 19:12, Ken Lunde lunde at adobe.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote:
> 
> Adam, 
> 
> I am of the opinion that the name.ID=6 strings of the fonts in a Font Collection must be unique, because many environments use this string to uniquely identify a font, but that the requirement that these strings match CFF.FontName be lifted only for Font Collections. The Source Han Sans OTCs have been deployed since mid-July of last year, and work in the environments that can consume CFF-based Font Collections, meaning OS X Version 10.8 or greater, and Adobe apps CS6 or greater. I am using the Super OTC, which has 28 fonts with seven 'CFF ' tables shared among them. 
> 
> Regards... 
> 
> -- Ken 
> 
> > On Apr 3, 2015, at 9:34 AM, Adam Twardoch (List) <list.adam at twardoch.com> wrote: 
> > 
> > Ken, 
> > 
> > thanks for this. Your e-mail just made me realize that due to the CFF.FontName limitation, it's not really possible to make a valid OTC with one name-keyed CFF and several cmap+name tables. 
> > 
> > I have made such TTC fonts where, instead of using the "smcp" GSUB feature, I made a second "cmap" table (and "name" table) that allowed some users to use the small caps in environments where certain or all user-controlled OpenType Layout features are not available — such as Microsoft Word (for "smcp") or OpenOffice. 
> > 
> > Could anyone remind us of the consequences of what'd happen if the CFF.FontName and name ID 6 don't match? 
> > 
> > Or of a situation when several "name" tables in an OTC use the *same* name ID 6 (but different Full Names etc.) 
> > 
> > Best, 
> > Adam 
> > 
> > Sent from my mobile phone. 
> > 
> > On 03.04.2015, at 18:18, Ken Lunde lunde at adobe.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote: 
> > 
> >> [Attachment(s) from Ken Lunde included below] 
> >> All, 
> >> 
> >> With regard to the proposed ISO/IEC 14496-22 Amendment to clarify Font Collections, I have some thoughts to share with the mailing lists. I have attached the document that Vladimir circulated for everyone's convenience. Hopefully this will drum up some discussion, which may lead to the actual amendment text. 
> >> 
> >> First, none of the issues are specific to a particular outline format, referring to the 'glyf' (TrueType), 'CFF ' (PostScript), and 'SVG ' tables. 
> >> 
> >> With regard to the "checkSumAdjustment" field of the 'head' table, long-time implementers of TrueType Collections, meaning Apple and Microsoft, are the ones who should weigh in on this particular issue. Given that the definition of this field is for a file, and because a Font Collection is merely a bucket of multiple 'sfnt' tables, and contains two or more "virtual" font files, my guess is that this field is ignored in the context of Font Collections. But again, Apple and Microsoft should weigh in for clarity and guidance. 
> >> 
> >> About which tables can and cannot be shared, my view is that the general principle should be that all tables can be shared, but to specify exceptions. The most obvious exception is the 'name' table, because it defines the name space for each font in the Font Collection, and thus must be unique. And, pending the outcome of the discussion above, the 'head' table may fall into this category as well. 
> >> 
> >> I have implemented three real-world use cases that demonstrate different degrees of table sharing, one of which has been deployed (the Adobe-branded Source Han Sans and the Google-branded Noto Sans CJK). 
> >> 
> >> Let me describe all three use cases. 
> >> 
> >> 1) Source Han Sans & Noto Sans CJK. These Pan-CJK fonts benefit from 'sfnt' table sharing in a very significant way. I summarized this in the following recent CJK Type Blog article: 
> >> 
> >> http://blogs.adobe.com/CCJKType/2015/03/collections.html 
> >> 
> >> We deployed two styles of CFF-flavor Font Collections. One style consisted of seven Font Collections, one per weight. Each Font Collection contains four fonts, one per language (Simplified Chinese, Traditional Chinese, Japanese, and Korean). The following tables are completely shared: 
> >> 
> >> BASE 
> >> CFF 
> >> GPOS 
> >> VORG 
> >> hhea 
> >> hmtx 
> >> maxp 
> >> post 
> >> vhea 
> >> vmtx 
> >> 
> >> The following tables are not shared (or at least, not completely): 
> >> 
> >> GSUB 
> >> OS/2 (partially shared) 
> >> cmap 
> >> head 
> >> name 
> >> 
> >> The other style is being called the Super OTC, which crams all four languages and all seven weights into a single Font Collection. The degree of sharing is different. For example, there are seven 'CFF ' and 'GPOS' tables, one for each weight, which are shared by the four languages. There are four 'GSUB' and 'cmap' tables, one per language, which are shared by all seven weights. (Note that this points out an error in the current standard that states that the 'cmap' and 'OS/2' tables should not be shared, but Source Han Sans disproves this.) There is similar sharing with other tables, but these are the big-ticket items that contribute to the footprint. If anyone wants a more detailed analysis of the extent to which tables are shared, please download and inspect the Font Collections in the Source Han Sans open source project: 
> >> 
> >> https://github.com/adobe-fonts/source-han-sans 
> >> 
> >> 2) Kozuka Pro + Pr6N. Although we have not yet released Font Collections based on our Kozuka fonts, Gothic and Mincho, I have assembled them for internal testing. This case is interesting as it relates to the 'CFF ' and 'maxp' tables. 
> >> 
> >> The Kozuka fonts are available in two flavors. One of them is based on Adobe-Japan1-4, which includes 15,444 glyphs (CIDs 0 through 15443), and are labeled as Pro fonts. The other is based on Adobe-Japan1-6, which includes 23,058 glyphs (CIDs 0 through 15443), and are labeled as Pr6N fonts. The 'CFF ' tables are in a pure superset/subset relationship, meaning that the glyphs of the Pro fonts are identical to CIDs 0 through 15443 of the Pr6N fonts. (The Pro fonts are JIS90-savvy, and the Pr6N fonts are JIS2004-savvy, but that is somewhat orthogonal, and handled via separate 'cmap' and 'GSUB' tables.) 
> >> 
> >> So, when I assembled the Font Collections, I forced the Pr6N 'CFF ' table to be shared. The current versions have separate 'maxp' tables that match the glyph count in the original 'CFF ' tables, but thinking about this further, for such pure superset/subset cases when multiple font instances share the same glyph table (CFF, glyf, or SVG), the 'maxp' of the actual 'CFF ' table in the Font Collection should be used. For our Kozuka fonts, this means that the 'maxp' table should be shared for the Pro and Pr6N fonts inside. 
> >> 
> >> 3) Kamono Kana. We developed a small set of kana-only Japanese fonts years ago, which are available in three styles (Logo Arl, Logo Cut, and Logo Line) and in four weights. When I built Font Collections, I combined all three styles, which meant that the main benefit was packaging, because the primary shared tables, 'cmap' and 'GSUB', are not big ticket items for such fonts. I could even build a Super OTC, but again, that would be mainly for packaging convenience, because there would still be 12 'CFF ' tables, and any sharing would be of the smaller tables. 
> >> 
> >> Lastly, the current standard specifies that the CFF.FontName and name.ID=6 (Postscript name for the font) strings must match, but this requirement should not (and need not) apply to CFF-based Font Collections. 
> >> 
> >> Regards... 
> >> 
> >> -- Ken 
> >> 
> >> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150403/ce932af0/attachment.html>