[mpeg-OTspec] RE: Proposed changes to the OFF specification

[mpsuzuki at hiroshima-u.ac.jp]

On Thu, 21 Jul 2011 08:01:41 -0400
"Levantovsky, Vladimir" <Vladimir.Levantovsky at MonotypeImaging.com>
wrote:

>I also would like to note that adding a new field in the OS/2 table (or
>any other table for that matter) would have a much more profound effect
>on all existing implementations and font development tools. Until the
>impact of such change is fully understood, modifying the spec seems
>risky and should probably be postponed until a broader discussion takes
>place. 

Indeed. Extension of the data format requires more discussion.
It is not what SC34 asked for, although some people may have
interest.

>There is still a chance that a simple change in the description of
>existing OS/2 'panose' field would satisfy the needs of the SC34 and
>the OOXML document format, but, again, we should first make sure that
>none of the existing implementation are directly affected by it.

Indeed. Already we have heard the comments from Microsoft that
their implementations are designed for genuine Panose but the
documentation (e.g. MSDN) was insufficient, but I've not heard
the comments from other important groups; Adobe, Apple, Bitstream,
IBM, MonoType, etc.

>As it stands right now, the 'panose' field of OS/2 table implements
>only a subset of the Panose specification. Changing this description to
>reference the original Panose spec would effectively mean removing any
>restrictions on the Panose values that can be encoded in the OS/2
>table. Some implementations that are conformant to genuine Panose spec
>may be fine with, while there may still be others that only implement a
>subset of Panose. It's feasible that such implementations can be easily
>updated to full Panose spec, but we do need to reach a consensus and
>make sure that we do not inadvertently introduce a breaking change in
>the OFF/OT spec.

I appreciate your careful attitude. If all important implementations
implement genuine Panose correctly and OFF/OT spec can remove its
"subsetted" definition safely, it is the best solution for SC34.

But even if some important implementations are found that implement
"subsetted" Panose and there is no consensus to drop the "subsetted"
Panose definition in OFF/OT spec, it is still acceptable for SC34.
SC34 will ask for the clarification that some existing implementations
of OFF/OT use "subsetted" Panose and their property ranges are
different from genuine one, in future revision of OFF/OT.

Regards,
mpsuzuki