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

[Adam Twardoch (List)]

But the thing would of course be that such an OTC would contain just one CFF table (which in PS/PDF sort of is "the font") with only one CFF.FontName, but that OTC would contain several "name" tables (and "cmap" tables). So what should each of the name IDs hold, in relation to the one CFF.FontName? 

A.

Sent from my mobile phone.

> On 03.04.2015, at 19:26, Jonathan Kew <jfkthame at gmail.com> wrote:
> 
>> On 3/4/15 17:34, 'Adam Twardoch (List)' list.adam at twardoch.com [mpeg-OTspec] 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.)
> 
> It seems likely this could lead to confusion (e.g. the wrong face being rendered) in environments where the PS name is used as the primary font identifier. PostScript printers come to mind, though they may not be the only cases that would be at risk.
> 
> Software (e.g. printer drivers) that is aware of the potential for distinct faces to have the same PS name could of course work around it, but relying on all relevant software to handle this correctly seems like a big gamble.
> 
> JK
>