Status of DR 09-0061
John Haug
johnhaug at exchange.microsoft.com
Wed May 2 01:29:37 CEST 2012
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
>
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DR 09-0061 changes v3.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 58895 bytes
Desc: DR 09-0061 changes v3.docx
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120501/c524017e/attachment-0001.bin>
More information about the sc34wg4
mailing list