Status of DR 09-0061

[John Haug]

I've taken a stab at updating the proposal for DR 09-0061 based on our call last week.  I figure it will need some input, so I've attached it for review and comments.

I have two questions in comments and I'd appreciate any suggestions on them.  Otherwise, I kept it short since it's not the place to get into all the historical complications of Panose.  The red faux tracked changes is Chris' original write-up.  The blue is my further changes.

Thanks,
John

From: John Haug [mailto:johnhaug at exchange.microsoft.com]
Sent: Thursday, March 22, 2012 12:08 PM
To: SC34
Cc: mpsuzuki at hiroshima-u.ac.jp
Subject: RE: Status of DR 09-0061

Here is a written form of what I talked through on the call today.  It was a lot to digest, so hopefully this is helpful to anyone who missed part of the discussion.  As discussed today, I'll look into Office's use of PANOSE (e.g., "v1.0" vs. "v1.5") and think more about Caroline's suggestion to include both regexes.  So far, I'm liking the idea, since it provides full info for a validation implementation to check any OOXML file, regardless of how the producer understands PANOSE-1 numbers.



The meeting I mentioned was primarily between Vladimir from Monotype (SC 29 member) and Greg Hitchcock (Microsoft font expert) in a lengthy discussion around how to handle the messy history of PANOSE* with respect to ISO/IEC 14496-22 (Open Font Format, the ISO version of OpenType).  SC 34/WG 2 had sent a liaison statement to SC 29 about changes they wanted to see to make PANOSE more usable for East Asian scripts which precipitated the meeting.  Our WG 4 involvement via the fonts DR was a separate issue, and dependent on what they decide.



Greg and Vladimir reached a delicate conclusion that PANOSE was never designed for extensibility and trying to make it workable for non-Latin fonts wasn't feasible because the core character measurements represented by the PANOSE fields are fundamentally Latin-oriented.  Further, because of the messy history of PANOSE, PANOSE numbers in fonts are frequently not reliable and many apps do not rely heavily on PANOSE information anymore.  They're going to preserve the current behavior, remove some restrictions about its use (which I think allows people to play unofficially with PANOSE fields, which sort of loosely satisfies WG 2) and make the reference from 14496-22 to the online PANOSE documentation (v"1.5", see below) informative.  For the WG 4 fonts DR, that means we ought to try to close the DR without action, since we'd be providing a restriction, albeit informative, based on something loosely defined in 14496-22 with an informative reference to the details.



* PANOSE has been around for a long time, last owned by ElseWare, bought by HP in the mid-90s.  Microsoft has documentation of PANOSE (call it "v1.0") it uses for TrueType/OpenType.   ElseWare made their own changes to PANOSE before stopping work on it.  These modified PANOSE docs (call it "v1.5") are published online for reference, though not really owned or maintained, by Monotype.  So, there are two different sets of PANOSE-1 documentation out there and people have coded to both, leaving PANOSE numbers in fonts unreliable to apps.



Other WG 4 discussion reference: http://mailman.vse.cz/pipermail/sc34wg4/2012-January/002560.html


From: eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com> [mailto:eb2mmrt at gmail.com]<mailto:[mailto:eb2mmrt at gmail.com]> On Behalf Of MURATA Makoto
Sent: Saturday, February 04, 2012 1:05 AM
To: SC34
Subject: Fwd: Status of DR 09-0061

Suzuki-san's document about DR 09-0061.  Sorry for this belated input.

Regards,
Makoto
Status of DR 09-0061, clarification of ST_Panose

2012-01-17

Source: suzuki toshiya, member of SC34/WG2, and the submitter of DR 09-0061

1. Introduction

DR 09-0061 was submitted by me in 2009, and it is now marked as closed, but its solution is not included in forthcoming Corrigendum. This document describes the current status of DR 09-0061.

2. Activities to close DR 09-0061 from previous Prague meeting 2011

The defect was difficult to close quickly, because existing specifications of OpenType (ISO/IEC 14496-22) refers genuine Panose at http://www.panose.com/<http://www.panose.com>, but the text in the spec was incompatible with genuine Panose spec. Also other documents related with existing implementations have incompatible definitions. After the long investigation by Chris Rae, it was commented that existing implementations had been designed to follow the genuine Panose.

During SC34/WG4 meeting at Prague in April 2011, Chris Rae from Microsoft and I reached an agreement how to close the defect; adding an informative regex to validate the Panose values included in OOXML document. Considering the exist of the fonts violating the Panose specified by Panose spec referred by ISO/IEC 14496-22 http://www.panose.com/, we decided that ISO/IEC 29500 should not include the normative text that classify them as invalid fonts. Also it was agreed that using existing reference ISO/IEC 14496-22 as the reference of Panose spec is better than adding yet-another reference for Panose. I drafted the regular expression based on http://www.panose.com/ spec, and Chris checked that it does not invalidates the fonts in existing implementations.

However, when I repored the inconsistency of genuine Panose spec and misleading text in ISO/IEC 14496-22 spec to SC29/WG11 (the group maintaining ISO/IEC 14496-22) and proposed to drop the misleading text in next version, the font experts in SC29/WG11 commented that it is incompatible change and further investigation is needed. Their feedback to SC34 is filed as SC34 N1663. Thus I stopped pushing the regex draft to DCOR. Greg Hitchcock, a participant in SC29/WG11 from Microsoft commented that the existing implementation follow to older revision of Panose spec which was different from current "genuine" spec at http://www.panose.com/. It makes difficult to determine appropriate document for the reference of Panose.

3. How to close DR 09-0061, and Schedule

Although SC29/WG11 recognized there is a problem, but unfortunately they have not decided how to fix it. Anyway, considering that both of http://www.panose.com/ and existing ISO/IEC 14496-22 is now known to be inappropriate reference for Panose, the solution should be the informative regex with the note that the regex is designed for the compatibility with the existing implementations of OOXML. The updated draft of regex is sent to Greg Hitchcock.

When SC34/WG4 holds a meeting in Prague, SC29/WG11 holds a meeting in San Jose. I asked whether SC29/WG11 can determine the schedule to update ISO/IEC 14496-22 spec to clarify their own Panose and waiting for their reply. However, if the regex for ST_Panose is defined for the compatibility with the existing implementation of ISO/IEC 29500 (not of ISO/IEC 14496-22), it would not have serious impact against ISO/IEC 14496-22.




--

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120327/18b2272c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0061 changes v2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 59376 bytes
Desc: DR 09-0061 changes v2.docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120327/18b2272c/attachment-0001.bin>