Fwd: Status of DR 09-0061

[MURATA Makoto]

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/, 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/20120204/792f98a8/attachment.htm>