<div class="gmail_quote">Suzuki-san's document about DR 09-0061.  Sorry for this belated input.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards,</div><div class="gmail_quote">Makoto<br>
<br><u></u>




<div>
<h1>Status of DR 09-0061, clarification of ST_Panose</h1>
<p>2012-01-17</p>
<p>Source: suzuki toshiya, member of SC34/WG2, and the submitter of DR 09-0061</p>
<h2>1. Introduction</h2>

<p>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.</p>

<h2>2. Activities to close DR 09-0061 from previous Prague meeting 2011</h2>

<p>The defect was difficult to close quickly, because existing
specifications of OpenType (ISO/IEC 14496-22) refers
genuine Panose at <a href="http://www.panose.com" target="_blank">http://www.panose.com/</a>,
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.
</p>

<p>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
<a href="http://www.panose.com/" target="_blank">http://www.panose.com/</a>, 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 <a href="http://www.panose.com/" target="_blank">http://www.panose.com/</a>
spec, and Chris checked that it does not invalidates the fonts
in existing implementations.</p>

<p>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 <a href="http://www.panose.com/" target="_blank">http://www.panose.com/</a>.
It makes difficult to determine appropriate document for the reference
of Panose.
</p>

<h2>3. How to close DR 09-0061, and Schedule</h2>

<p>Although SC29/WG11 recognized there is a problem, but unfortunately
they have not decided how to fix it. Anyway, considering that both of
<a href="http://www.panose.com/" target="_blank">http://www.panose.com/</a> 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.
</p>

<p>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.
</p>

</div>

<br></div><br><br clear="all"><div><br></div>-- <br><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto<br>