Panose issue status? (Re: [mpeg-OTspec] AHG activity kick-off)

Tue Jan 24 23:17:20 CET 2012

All,

-- What Adobe does:

1. Adobe's fonts don't set OS/2.panose in the "static" way that Greg says the field was intended and originally specified. They set it in the way described by the monotypeimaging.com link in the current OS/2.panose spec. This means that our bFamilyType 3 and 4 fonts "won't work" with GDI's (or any other static interpretation engine's) usage, but our bFamilyType 2 fonts will be OK in this regard.

2. Adobe's font engines have very little use of OS/2.panose. When it is used, it is read in a "static" way. Its use is marginal enough that it should not be a factor in determining the outcome of this issue.

-- My thoughts on the proposal:

It seems to me that GDI's "static" interpretation reading of the field coupled with Greg's clarification of the intent of the field should result in the specification being clarified to be the "static" interpretation. 

Unfortunately, this means that some fonts may need to be revised. However, updating the fonts may not need to be a high priority since only bFamilyType 3 and 4 fonts will be affected. In fact, Adobe hasn't heard bugs reported around this issue.

If there is software out there that reads the field in the non-static way and cares about it enough, then perhaps an OS/2 version bump can be proposed to accompany this clarification of OS/2.panose. Thus, if the OS/2 version is >= 5, then OS/2.panose is definitely set according to the "static" interpretation. If the version is < 5, then how OS/2.panose is set is ambiguous (though various heuristics may be employed to detect this).

However, I'm not sure the version bump is worth the bother. If a font engine cares enough about it, a simple heuristic could be employed that checks against combinations of valid sets of ranges. Anyone care to take a stab at such a heuristic? If it's sufficient, perhaps it could be in the Recommendations section.

Since Panose doesn't address non-Latin scripts, I'm hesitant to promote it even more by adding a new "Panose 1.1" field to the end of the OS/2 table, unless there are compelling arguments for doing so.

Thoughts? 

Sairus

-----------------

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of suzuki toshiya
Sent: Thursday, January 19, 2012 10:17 PM
To: Greg Hitchcock
Cc: David Lemon; Levantovsky, Vladimir; OTspec
Subject: Re: Panose issue status? (Re: [mpeg-OTspec] AHG activity kick-off)

Dear Greg,

Thank you for reply, with concrete option.
I think your proposal is reasonable because the web page you
gave would be one of the most referred one, and the impact
to the existing implementation would be minimized.

Maybe asking for the description about the measurement from
non-LatinText typeface to the values designed for LatinText typeface
would be slightly out of scope of ISO/IEC 14496-22 maintenance,
but I have to point it out that there is a mismatch between
http://panose.com/ versus Microsoft's OpenType spec, even if
we restrict the scope to LatinText.

In http://panose.com/ spec, the range of Stroke Variation byte
is 0x00-0x0A. In Microsoft's OpenType spec, the range of
bStrokeVariation is 0x00-0x08.

The symbolic names of the decimal values are different as
following:
panose.com syntax: 0x00=any, 0x01=no_fit, 0x02=no_variation, 0x03=gradual_diagonal, ..., 0x09=instant_vertical, 0x0A=instant_horizontal
Microsoft syntax: 0x00=any, 0x01=no_fit, 0x02=gradual_diagonal, ..., 0x08=instant_vertical

There is something like off-by-one issue.

Thus, I ask for the consideration to add a description about
how the invalid values should be dealt.

Regards,
mpsuzuki

Greg Hitchcock wrote:
> From my point of view, I'd consider the "official" PANOSE specification for *OpenType* to be http://www.microsoft.com/Typography/otspec/os2ver1.htm#pan . The documentation on http://panose.com was *only* meant as a guide for how to calculate the values.

> 
> The primary difference between this one and http://panose.com is the keying off of the family kind field in order to define the later PANOSE fields and the adjustments for Stroke Variation.
> With the former, the fields in the OS/2 spec were always meant to be static. With the later, I've recently become aware of this and I'll try to see where the change crept in.
> 
> Greg
> 
> -----Original Message-----
> From: suzuki toshiya [mailto:mpsuzuki at hiroshima-u.ac.jp] 
> Sent: Sunday, January 15, 2012 11:53 PM
> To: Greg Hitchcock; David Lemon
> Cc: Levantovsky, Vladimir; OTspec
> Subject: Panose issue status? (Re: [mpeg-OTspec] AHG activity kick-off)
> 
> Dear Greg and David,
> 
> If you got any investigation results on the difference between http://panose.com/ versus the Panose assumed by existing implementation, could you post to the list?
> 
> In my understanding; during the discussion about Panose spec clarification in July 2011, you had expressed the concern that the Panose data structure assumed by the existing implementations by Microsoft and Adobe might be different from the spec currently published via http://panose.com/, so referring the latest official Panose as the normative part of the standard might introduce some incompatibility issues between the existing font processing system versus the standard 'conforming'
> fonts. Also I'm interested in hearing the comments by other experts dealing with different existing implementations (e.g. Apple).
> 
> Panose is used by several dejure or defacto standards (e.g. CSS, SVG, OOXML, etc), but the implmentation around OpenType would be the most respected one. If the latest official Panose at http://panose.com is not appropriate spec for OpenType implementation to refer normatively, ISO/IEC 14496-22 is expected to define what should be referred.
> 
> When SC29/WG11 is held in San Jose, SC34/WG4 (OOXML maintenance WG) is held in Prague, Checz. So as a member of SC34, I want to know what kind of inputs are prepared for next SC29/WG11 meeting.
> 
> Regards,
> suzuki toshiya, Hiroshima University, Japan member of SC34
> 
> Levantovsky, Vladimir wrote (2011/12/22 0:59):
>> Dear AHG members,
>>
>> The next WG11 )MPEG) meeting will take place in early February (Feb. 6-10, 2-12) in San Jose, CA. The meeting notice can be found at:
>> http://registrationassistant.com/meetingplanit/2012ISO/default.asp
>>
>> The AHG mandate for this period includes the following items:
>>
>> 1. To study the text of the amendment ISO/IEC 14496-22/DAM2 "Open Font Format, Amendment 2: Additional script and language tags"
>>
>> 2. To study the text of the ISO/IEC 14496-28/DIS "Composite font representation"
>>
>> (Both 14496-22 and 14496-28 documents are currently under open ballots 
>> that will be closed in the end of January.)
>>
>>
>> 3. To study the impact of the proposed changes to OS/2 'Panose' field on the existing implementations and to recommend a way the proposed changes can be implemented
>>
>> As you remember, a proposal has been made to extend Panose settings to improve classification for non-Latin scripts. I would like to us to continue the discussion and come up with the recommendations for WG11 to proceed.
>>
>>
>> 4. To conduct exploration activities on integrating SVG as new glyph description format in OFF in collaboration with the W3C
>>
>> 5. To collect and evaluate the proposed changes and improvements to the OFF standard and produce a report with recommended work items for WG11
>>
>> A new proposal to extend OFF/OpenType capabilities using SVG glyph descriptions to support multi-colored glyphs and animations had been made earlier this year and the discussions are now conducted in W3C Community group http://www.w3.org/community/svgopentype/. I would like to invite all interested parties to contribute to this discussion.
>>
>> Over the last few months, a number of the proposed changes were 
>> submitted to the AHG email list with the intent to improve the clarity 
>> of the spec and to correct some wording and minor mistakes in the text 
>> of the standard. I would like us to finalize the list of changes we 
>> want to see implemented in the spec and produce a recommendation to 
>> MPEG on how to proceed. Since the second edition of the OFF standard 
>> was published (which is identical to OpenType ver. 1.6), we already 
>> had two amendments (including the current one) and one corrigendum. 
>> According to the ISO process document, the next set of changes would 
>> need to be implemented as a new edition of the standard, which makes 
>> sense considering not only the changes and clarifications in the 
>> current text but also a new addition of the SVG functionality in the 
>> future standard (subject to reaching a consensus among all group 
>> members). Therefore, I would like to suggest that we should plan our 
>> work as an exploration activity fo
> r SVG glyphs and to collect and finalize the list of all changes that need to be implemented in the next edition of the standard.
>> Thank you and happy holidays!
>> Vladimir
>>
>>
> 
> 
> 