[mpeg-OTspec] Proposed changes to the OFF specification

[mpsuzuki at hiroshima-u.ac.jp]

Dear all,

I'm sorry for lated response about this issue.

The background of the liaison comment from SC34 to SC29/WG11 was:
ISO/IEC 29500 (so-called OOXML by Microsoft) includes the Panose
values in the document to help the font substitution. Because ISO/
IEC 29500 includes XML schema to validate the document, SC34 expects
some ISO spec that clarifies the valid ranges of Panose values.
Mainly the Panose values in the document are copied from OFF
resources, SC34 expects that OFF spec is good reference.

On Wed, 6 Jul 2011 10:19:07 -0400
"Levantovsky, Vladimir" <vladimir.levantovsky at monotypeimaging.com>
wrote:

>On Tuesday, July 05, 2011 5:52 PM James Cloos wrote:
>> 
>> It seems that dropping the panose info would make accurate
>> classification not more likely but rather less likely.
>
>Agree, but I don't think dropping Panose is what's been proposed. The
>proposal (read the last sentence of the section entitled "Discussion in
>SC34") is to keep Panose as the classification system, but to drop the
>actual property names from the OS/2 spec and to reference the Panose
>specification to define them. As of today
>(http://www.microsoft.com/typography/otspec/os2.htm#pan), the property
>names listed in the OS/2 table description only mention properties that
>are defined in Section 2 of Panose spec for Latin text. Other sections
>(3 - 5) of Panose use the same 10 byte arrays but define slightly
>different set of properties.

Thank to Vladimir for clarification, your explanation is correct.
SC34 does not propose to drop Panose from OFF spec. SC34 expects
the more clarification about Panose related text in OFF, to prevent
misunderstanding. Current OFF (and Opentype) spec lists 10 variable
names for Panose. It makes the readers assume the properties reminded
by the names would be written. But it is misunderstanding. The
coverage of the Panose properties are dependent with the family kind
classification. Some properties are only available in Text,
unavailable in Symbol (Symbol has no xheight, no serif style).
The easiest solution would be the dropping the variable names from
OFF spec and just refer the Panose spec for further information of
each octets.

If it is difficult for the users, giving per-family-kind variable
name list would be good to prevent misunderstanding. I'm not sure
if original OS/2 table designer (before OpenType) was understanding
Panose correctly, I'm afraid that he copies the names from GDI header
files of Microsoft Win32 API. There was an anxiety that Microsoft GDI
implementation is based on the wrong understanding of Panose properties,
but Microsoft experts in SC34 commented that Microsoft implementsthe
correct Panose spec, but the documentation was incorrect. Thus,
personally, I think changing the variable names from current list to
more correctly detailed list, it won't be a big impact. However,
there is a possibility that Panose can be updated in future, having
a Panose variable name list in OFF spec requires the effort to
maintain it.
 
>> Even if the original authors of panose did not envision certain
>> combinations, that does not imply that those combinations are
>> useless.
>> 
>
>Right, and the liaison also seem to emphasize it when they refer to a
>specific [international] descriptor of the Panose field that says that
>"Additional specifications are required for PANOSE to classify
>non-Latin character sets".

On the issue that genuine Panose spec is defined for Latin script
and other scripts had been left as future task, SC34 wants to
retain the text in OFF spec, because it is informative to indicate
that Panose spec itself does not request to classify non-Latin
typeface by the properties designed for Latin script.

>I wonder if Suzuki-san (copied on this email) may be able to offer more
>details about this liaison and whether my understanding of the proposal
>is correct.
>
>Thank you,
>Vladimir

Your explanation is correct, thank you again.

Regards,
suzuki toshiya, SC34/WG2 member