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

[suzuki toshiya]

Dear Sairus,

Many thanks to the information how Adobe uses OS/2.panose,
it is important to know the exist of the fonts following to
panose.com syntax.

Also thank you for comment about the heuristic handling.

In my investigation on the fonts bundled to Microsoft Windows 7,
Mac OS X 10.5, and the free fonts distributed in Debian GNU/Linux,
some of them are violating panose.com syntax, but none of them
are violating GDI syntax.

I think, dealing the font violating panose.com syntax but keeping
GDI syntax as the font assuming GDI syntax is reasonable.

It is difficult to determine the assumed syntax of the font that
does not violate both syntax. And, even if we restrict the scope
to LatinText, there is a off-by-one issue (as described in my
previous post) in StrokeVariation. I will check how the value
is used in most fonts.

--

Previous bumping of OS/2 version had remarkable advantage to use
new one, especially the information of supported Unicode ranges
were updated. Considering that OS/2 ver2 and OS/2 ver3 had a
small difference in the comment about how to calculate average
character width, updating the Panose definition in next version
of OS/2 table would be appropriate idea, I think.

However, bumping the OS/2 version is not crucial solution, because
previous Microsoft OpenType spec and ISO/IEC 14496-22 had recommended
to set Panose value. Even if it is non-normative part, how existing
implementation had dealt the Panose values should be described.

In ISO/IEC 29500 (OOXML) spec maintained by SC34/WG4, I will propose
to add XML regular expression to validate Panose value with GDI syntax,
to non-normative part. Also it will be documented as "validation for
existing implementation of OOXML", not as "validation for ISO/IEC
14496-22".

Regards,
mpsuzuki

Sairus Patel wrote:
> 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
>>>
>>>
>>
>>
> 
>