Status of DR 09-0061

Sat May 5 10:54:08 CEST 2012

Dear John,

Thank you for updated text. I think it is OK to close DR 09-0061 !

Regards,
mpsuzuki

John Haug wrote:
> I've integrated Suzuki-san's changes (with a few modifications to wordsmith it) in the attached.  I also cleaned up the dueling red and blue changes since the doc had tracked changes from both Chris and I.  It's much simpler to see the net proposed differences now.
> 
> John
> 
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Thursday, April 26, 2012 6:16 AM
> To: SC34
> Subject: Fwd: Status of DR 09-0061
> 
> ---------- 転送メッセージ ----------
> From: suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp>
> 日付: 2012年4月25日16:27
> 件名: Re: Status of DR 09-0061
> To: John Haug <johnhaug at exchange.microsoft.com>
> Cc: SC34 <e-SC34-WG4 at ecma-international.org>, MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
> 
> 
> Dear John,
> 
> Thank you for drafting to close DR 09-0061, here I send my proposal.
> My changes are following:
> 
> * The relationship of 2 different Panose spec is described briefly;
> - new (dated 1997) one, referred by ISO/IEC 14496-22:2009.
> - older one, used by existing implementation of ISO/IEC 29500.
> 
> * The handling of the values that are valid in new spec but invalid in older spec would be application dependent.
> 
> * It is noted that the set of 3 regex is for older spec, the set of
> 6 regex is for newer spec.
> 
> * The method to normalize the invalid values to fit newer spec is dropped, because the handling of invalid values are already noted as application dependent.
> 
> I wish we can close this DR in next WG4 meeting
> 
> Regards,
> mpsuzuki
> 
> (2012/03/27 9:38), John Haug wrote:
>> 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
>>
> 
> 
> 
> 