Fwd: Status of DR 09-0061

Thu Apr 26 15:16:03 CEST 2012

---------- 転送メッセージ ----------
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
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0061 changes v2.5.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 61274 bytes
Desc: not available
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120426/4f4cccf7/attachment-0001.bin>