[mpeg-OTspec] Proposed OS/2 table updates

[Michelle Perham]

Thanks for the feedback. The original intention was that name table ID 16 (Preferred Family Name) could be used to group fonts together that are in the same family but that vary in optical style. For example, the Sitka family has ID 16 set to “Sitka” for all fonts. An operating system can search for all fonts with ID 16 = “Sitka”, then use the OS/2 size values to differentiate the optical styles. This enables operating systems to group fonts based on optical styles just as they do weight, width, and slope.

As several people have pointed out, this doesn’t work in all cases. For example, if a foundry wants to group fonts together with the same value for ID 16, but include in that set fonts that vary in other ways than weight, width, slope, and optical size. For example, if Sitka had an informal variant, the above would require it to have ID 16 = “Sitka Informal”, thus it would not group with “Sitka”.

We’re looking into this and will get back to this group. We also welcome ideas others have.

Michelle

-----Original Message-----
From: John Hudson [mailto:john at tiro.ca] 
Sent: Friday, May 16, 2014 1:51 AM
To: David Lemon; mpeg-OTspec at yahoogroups.com
Cc: Michelle Perham
Subject: Re: [mpeg-OTspec] Proposed OS/2 table updates

On 17-May-14 01:20, David Lemon lemon at adobe.com [mpeg-OTspec] wrote:

> The proposal below is missing a mechanism to identify the set of fonts 
> that work together as a series of optical size ranges. In families 
> that go beyond the simple four-style model (Regular, Bold, Italic, & 
> Bold
> Italic) I believe it’s necessary to include some means of associating 
> the correct set of fonts. That’s why the earlier ‘SIZE’ layout feature 
> included this information. I thought that there was going to be an 
> update to the proposal to include this. I don’t think it makes sense 
> to add this to the spec if a patch is on the way.
>
> FWIW Adobe was going to add this feature to our fonts two months ago 
> but remains blocked by the absence of the missing piece.

Michelle, can you follow up with Greg on this? We discussed this issue at the recent OTL engine developer meeting in Seattle, and looked at a couple of options for adding the kind of mechanism that David identifies. There seemed to be general agreement at the meeting that such a mechanism is, indeed, needed, and I think it would be a good idea to get this agreed on and spec'd before updating the OS/2 table with a partial implementation.

My own suggestion is that two additional fields be added to the OS/2 table which would point to enumerated name table fields, and that the format for these would be identical to those spec'd in the old GPOS 'size' feature. This would enable fonts that contain such name fields already to be very easily updated to work with the new OS/2 size data.

JH