<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>RE: Panose issue status? (Re: [mpeg-OTspec] AHG
activity k</title></head><body>
<div>Michelle (et al.),</div>
<div>Thanks for your flexibility on this. I believe that this really
is a positive outcome in the balance.</div>
<div>- thanks,</div>
<div> David L</div>
<div><br></div>
<div><br></div>
<div>At 9:41 AM -0700 7/16/12, Michelle Perham wrote:</div>
<blockquote type="cite" cite>We've had a bit more time to
investigate this issue further. Considering the fact that the majority
of the new implementations are based on Panose 1.5 - Microsoft
agrees with the proposal to remove Panose 1.0 values from OS/2
description and simply reference the 1.5 spec as is.</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>Michelle</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite><b>From:</b> mpeg-OTspec@yahoogroups.com
[mailto:mpeg-OTspec@yahoogroups.com]<b> On Behalf Of</b> suzuki
toshiya<br>
<b>Sent:</b> Thursday, January 19, 2012 10:17 PM<br>
<b>To:</b> Greg Hitchcock<br>
<b>Cc:</b> David Lemon; Levantovsky, Vladimir; OTspec<br>
<b>Subject:</b> Re: Panose issue status? (Re: [mpeg-OTspec] AHG
activity kick-off)</blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite> </blockquote>
<blockquote type="cite" cite>Dear Greg,<br>
<br>
Thank you for reply, with concrete option.<br>
I think your proposal is reasonable because the web page you<br>
gave would be one of the most referred one, and the impact<br>
to the existing implementation would be minimized.<br>
<br>
Maybe asking for the description about the measurement from<br>
non-LatinText typeface to the values designed for LatinText
typeface<br>
would be slightly out of scope of ISO/IEC 14496-22 maintenance,<br>
but I have to point it out that there is a mismatch between<br>
<a href="http://panose.com/">http://panose.com/</a> versus Microsoft's
OpenType spec, even if<br>
we restrict the scope to LatinText.<br>
<br>
In <a href="http://panose.com/">http://panose.com/</a> spec, the range
of Stroke Variation byte<br>
is 0x00-0x0A. In Microsoft's OpenType spec, the range of<br>
bStrokeVariation is 0x00-0x08.<br>
<br>
The symbolic names of the decimal values are different as<br>
following:<br>
panose.com syntax: 0x00=any, 0x01=no_fit, 0x02=no_variation,
0x03=gradual_diagonal, ..., 0x09=instant_vertical,
0x0A=instant_horizontal<br>
Microsoft syntax: 0x00=any, 0x01=no_fit, 0x02=gradual_diagonal, ...,
0x08=instant_vertical<br>
<br>
There is something like off-by-one issue.<br>
<br>
Thus, I ask for the consideration to add a description about<br>
how the invalid values should be dealt.<br>
<br>
Regards,<br>
mpsuzuki<br>
<br>
Greg Hitchcock wrote:<br>
> From my point of view, I'd consider the "official"
PANOSE specification for *OpenType* to be <a
href="http://www.microsoft.com/Typography/otspec/os2ver1.htm#pan"
>http://www.microsoft.com/Typography/otspec/os2ver1.htm#pan</a> . The
documentation on <a href="http://panose.com">http://panose.com</a> was
*only* meant as a guide for how to calculate the values.<br>
><br>
> The primary difference between this one and <a
href="http://panose.com">http://panose.com</a> is the keying off of
the family kind field in order to define the later PANOSE fields and
the adjustments for Stroke Variation.<br>
> With the former, the fields in the OS/2 spec were always meant to
be static. With the later, I've recently become aware of this and I'll
try to see where the change crept in.<br>
><br>
> Greg<br>
><br>
> -----Original Message-----<br>
> From: suzuki toshiya [mailto:<a
href="mailto:mpsuzuki%40hiroshima-u.ac.jp">mpsuzuki@hiroshima-u.ac.jp</a
>]<br>
> Sent: Sunday, January 15, 2012 11:53 PM<br>
> To: Greg Hitchcock; David Lemon<br>
> Cc: Levantovsky, Vladimir; OTspec<br>
> Subject: Panose issue status? (Re: [mpeg-OTspec] AHG activity
kick-off)<br>
><br>
> Dear Greg and David,<br>
><br>
> If you got any investigation results on the difference between <a
href="http://panose.com/"> http://panose.com/</a> versus the Panose
assumed by existing implementation, could you post to the list?<br>
><br>
> In my understanding; during the discussion about Panose spec
clarification in July 2011, you had expressed the concern that the
Panose data structure assumed by the existing implementations by
Microsoft and Adobe might be different from the spec currently
published via <a href="http://panose.com/,">http://panose.com/,</a> so
referring the latest official Panose as the normative part of the
standard might introduce some incompatibility issues between the
existing font processing system versus the standard
'conforming'</blockquote>
<blockquote type="cite" cite>> fonts. Also I'm interested in
hearing the comments by other experts dealing with different existing
implementations (e.g. Apple).<br>
><br>
> Panose is used by several dejure or defacto standards (e.g. CSS,
SVG, OOXML, etc), but the implmentation around OpenType would be the
most respected one. If the latest official Panose at <a
href="http://panose.com">http://panose.com</a> is not appropriate spec
for OpenType implementation to refer normatively, ISO/IEC 14496-22 is
expected to define what should be referred.<br>
><br>
> When SC29/WG11 is held in San Jose, SC34/WG4 (OOXML maintenance
WG) is held in Prague, Checz. So as a member of SC34, I want to know
what kind of inputs are prepared for next SC29/WG11 meeting.<br>
><br>
> Regards,<br>
> suzuki toshiya, Hiroshima University, Japan member of SC34<br>
><br>
> Levantovsky, Vladimir wrote (2011/12/22 0:59):<br>
>> Dear AHG members,<br>
>><br>
>> The next WG11 )MPEG) meeting will take place in early
February (Feb. 6-10, 2-12) in San Jose, CA. The meeting notice can be
found at:<br>
>> <a
href=
"http://registrationassistant.com/meetingplanit/2012ISO/default.asp"
>http://registrationassistant.com/meetingplanit/2012ISO/default.asp</a
><br>
>><br>
>> The AHG mandate for this period includes the following
items:<br>
>><br>
>> 1. To study the text of the amendment ISO/IEC 14496-22/DAM2
"Open Font Format, Amendment 2: Additional script and language
tags"<br>
>><br>
>> 2. To study the text of the ISO/IEC 14496-28/DIS
"Composite font representation"<br>
>><br>
>> (Both 14496-22 and 14496-28 documents are currently under
open ballots<br>
>> that will be closed in the end of January.)<br>
>><br>
>><br>
>> 3. To study the impact of the proposed changes to OS/2
'Panose' field on the existing implementations and to recommend a way
the proposed changes can be implemented<br>
>><br>
>> As you remember, a proposal has been made to extend Panose
settings to improve classification for non-Latin scripts. I would like
to us to continue the discussion and come up with the recommendations
for WG11 to proceed.<br>
>><br>
>><br>
>> 4. To conduct exploration activities on integrating SVG as
new glyph description format in OFF in collaboration with the W3C<br>
>><br>
>> 5. To collect and evaluate the proposed changes and
improvements to the OFF standard and produce a report with recommended
work items for WG11<br>
>><br>
>> A new proposal to extend OFF/OpenType capabilities using SVG
glyph descriptions to support multi-colored glyphs and animations had
been made earlier this year and the discussions are now conducted in
W3C Community group <a
href="http://www.w3.org/community/svgopentype/"
>http://www.w3.org/community/svgopentype/.</a> I would like to invite
all interested parties to contribute to this discussion.<br>
>><br>
>> Over the last few months, a number of the proposed changes
were<br>
>> submitted to the AHG email list with the intent to improve
the clarity<br>
>> of the spec and to correct some wording and minor mistakes in
the text<br>
>> of the standard. I would like us to finalize the list of
changes we<br>
>> want to see implemented in the spec and produce a
recommendation to<br>
>> MPEG on how to proceed. Since the second edition of the OFF
standard<br>
>> was published (which is identical to OpenType ver. 1.6), we
already<br>
>> had two amendments (including the current one) and one
corrigendum.<br>
>> According to the ISO process document, the next set of
changes would<br>
>> need to be implemented as a new edition of the standard,
which makes<br>
>> sense considering not only the changes and clarifications in
the<br>
>> current text but also a new addition of the SVG functionality
in the<br>
>> future standard (subject to reaching a consensus among all
group<br>
>> members). Therefore, I would like to suggest that we should
plan our<br>
>> work as an exploration activity fo<br>
> r SVG glyphs and to collect and finalize the list of all changes
that need to be implemented in the next edition of the standard.<br>
>> Thank you and happy holidays!<br>
>> Vladimir<br>
>><br>
>><br>
><br>
><br>
></blockquote>
<blockquote type="cite" cite></blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>David Lemon<br>
Sr Manager, Type Development<br>
Adobe Systems, Inc.<br>
<br>
408 536 4152<br>
lemon@adobe.com<br>
http://blogs.adobe.com/typblography</div>
</body>
</html>