<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16705" name=GENERATOR></HEAD>
<BODY style="BACKGROUND-COLOR: #ffffff">
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008>Dear mpsuzuki-san,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008>Thank you for your additional clarifications. I am not
sure when and why the text of the note was removed from the ISO text. I suspect
that it may have happened during one of the editing periods due to the fact that
the text of the note was referring to a specific proprietary extension not
supported by OFF specification.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008>Best regards,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008>Vladimir</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=443545719-05092008></SPAN></FONT> </DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpeg-OTspec@yahoogroups.com
[mailto:mpeg-OTspec@yahoogroups.com] <B>On Behalf Of
</B>mpsuzuki@hiroshima-u.ac.jp<BR><B>Sent:</B> Friday, September 05, 2008 3:24
PM<BR><B>To:</B> Levantovsky, Vladimir<BR><B>Cc:</B> mihill@microsoft.com;
mpeg-OTspec@yahoogroups.com<BR><B>Subject:</B> Re: [mpeg-OTspec] AHG on Open
Font Format kick-off<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV id=ygrp-text>
<P>Dear Vladimir Levantovsky,<BR><BR>Great thank you for quick
reply.<BR><BR>On Fri, 5 Sep 2008 14:54:46 -0400<BR>"Levantovsky, Vladimir"
<<A
href="mailto:Vladimir.Levantovsky%40MonotypeImaging.com">Vladimir.Levantovsk<WBR>y@MonotypeImagin<WBR>g.com</A>>
wrote:<BR>>I will edit the header title for 'kern' table as you
suggested.<BR><BR>Thank you!<BR><BR>>The "Recommendation" section (I
believe this is what you were referring<BR>>to as "cross-platform notes")
has not been dropped. The whole section is<BR>>in the text of the ISO/IEC
14496-22, clause 6 "Recommendations" (you can<BR>>find comments specific to
'kern' table on page 365 of the current draft<BR>>FCD, and comments on
'cmap' table on page 364).<BR><BR>I'm quite sorry that my previous message
lacked the exact<BR>reference. The "cross-platform notes" I mentioned was
the<BR>beginning of kern table description in OpenType spec, here<BR>I
quote:<BR><BR><A
href="http://www.microsoft.com/typography/otspec/kern.htm">http://www.microsof<WBR>t.com/typography<WBR>/otspec/kern.<WBR>htm</A><BR><BR>kern
- Kerning<BR><BR>NOTE: Apple has extended the definition of the
'kern'<BR>table to provide additional functionality.<BR>The Apple extensions
are not supported on Windows.<BR>Fonts intended for cross-platform use or for
the Windows<BR>platform in general should conform to the 'kern'
table<BR>format specified here.<BR><BR>I think this note is not included in
ISO/IEC 14496-22.<BR>The recommendation for kern table describes how to
make<BR>a kern table working on Windows, but does not mention<BR>about Apple
platform.<BR><BR>>As far as 'kern' table and subtable version numbers and
field<BR>>definitions are concerned - the current text is identical to
original<BR>>text of OpenType specification 1.4 and 1.5. I f you believe it
would be<BR>>beneficial to modify / update the field descriptions - we
would need to<BR>>discuss and approve these changes as part of the
established ISO ballot<BR>>process. AHG can not make these decision on its
own, without having it<BR>>discussed and approved by the SC29/WG11. I would
encourage you to submit<BR>>your comments and proposals as FCD ballot
National Body comments.<BR><BR>OK, the compatibility between ISO/IEC 14496-22
and<BR>OpenType spec would be most prioritized task, I
understand.<BR>Fortunately, this is the compatibility issue with
discouranged<BR>legacy implementation and the urgent standardization is not
essential<BR>(Apple 16bit kern is already discouraged in Apple TrueType
spec).<BR>I will try to discuss with Apple engineers and propose the
change<BR>of OpenType spec 1.7 or later (if Apple engineers think
it's<BR>important).<BR><BR>Thank you very
much,<BR>mpsuzuki<BR><BR>><BR>> From: <A
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@<WBR>yahoogroups.<WBR>com</A><BR>>[mailto:<A
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@<WBR>yahoogroups.<WBR>com</A>]
On Behalf Of<BR>><A
href="mailto:mpsuzuki%40hiroshima-u.ac.jp">mpsuzuki@hiroshima-<WBR>u.ac.jp</A><BR>>
Sent: Friday, September 05, 2008 2:23 PM<BR>> To: Levantovsky,
Vladimir<BR>> Cc: <A
href="mailto:mihill%40microsoft.com">mihill@microsoft.<WBR>com</A>; <A
href="mailto:mpeg-OTspec%40yahoogroups.com">mpeg-OTspec@<WBR>yahoogroups.<WBR>com</A><BR>>
Subject: Re: [mpeg-OTspec] AHG on Open Font Format kick-off<BR>> <BR>>
<BR>><BR>> Dear Vladimir Levantovsky,<BR>> <BR>> I'm quite sorry
for writing the comment on 2nd FCD in the<BR>> near of deadline.<BR>>
<BR>> Recently I've discussed about the implementation of "kern"<BR>>
table with Joshua Hadley, in OpenType mailing list, and<BR>> read the
corresponding parts of existing specifications.<BR>> Then, I find that I
should comment a few points.<BR>> <BR>> Editiorial comment<BR>>
------------<WBR>------<BR>> <BR>> In Contents page iv, the most titles
of the sections for<BR>> OFF tables are in the style like "cmap - Character
to Glyph<BR>> Index Mapping Table". But the title of the section
for<BR>> kern table is just "Kerning". I think "kern - Kerning"<BR>> is
compatible with other titles, and compatible with<BR>> OpenType
spec<BR>>(<A
href="http://www.microsoft.com/typography/otspec/kern.htm">http://www.microsof<WBR>t.com/typography<WBR>/otspec/kern.<WBR>htm</A><BR>><<A
href="http://www.microsoft.com/typography/otspec/kern.htm">http://www.microsof<WBR>t.com/typography<WBR>/otspec/kern.<WBR>htm</A>>
)<BR>> <BR>> non-Editiorial comment (maybe)<BR>>
------------<WBR>---------<WBR>---------<BR>> <BR>> Although ISO/IEC
14496-22 doesn't mention about how to design<BR>> a cross-platform kern
table, the existing specifications of<BR>> Apple TrueType GX, Microsoft
TrueType, and OpenType note<BR>> about how to make a cross-platform kern
table. Yet I've not<BR>> tracked the reason why the cross-platform notes is
dropped<BR>> in ISO/IEC 14496-22.<BR>> <BR>> If ISO/IEC
JTC1/SC29/WG11 experts discussed and concluded<BR>> as it should be removed
due to unavoidable incompatibilities,<BR>> the discussion is worthful, I
wish it should be commented<BR>> in ISO/IEC 14496-22 (even if it's out of
main sections).<BR>> <BR>> In addition, there is an important note for
kern table in<BR>> the recommendation: Microsoft Windows uses only the
first<BR>> subtable in format 0, for horizontal/no
cross-stream/<WBR>no<BR>> override. I wish if it's so important and should
be moved<BR>> to or repeated in the main section for kerning table.<BR>>
It is possible for a careful reader to recognize that<BR>> the subtable
format 2 is not supported by Windows nor OS/2,<BR>> but it is difficult to
recognize that multiple subtable<BR>> is not supported by Windows.<BR>>
<BR>> # In the case of cmap table, the information "how to<BR>> #
implement cmap table including UCS-4 characters" is<BR>> # written in the
subsection for cmap subtable format 12<BR>> # and repeated in the
recommendation.<BR>> <BR>> Also, a few definitions of the elements are
slightly unclear.<BR>> <BR>> "version" element in the head of kern
table:<BR>> This element is described as "starts at 0".<BR>> At present,
there's no description about the<BR>> number of version for "kern" table, I
think<BR>> "Set to 0" is better. Why? Although it is out<BR>> of the
scope of OpenType specification, Microsoft<BR>> platform seems to ignore
this element at all and<BR>> Apple platform seems to distinguish
original<BR>> 16bit kern versus 32bit TrueType GX kern.<BR>> To
disambiguify, giving only version 0 is better.<BR>> I wish if version 1 is
described as reserved<BR>> (as kern subtable format number 1 and 3
are<BR>> described as "reserved for future use").<BR>> <BR>>
"version" element in the head of kern sub table:<BR>> This element is
described as "Kern subtable<BR>> version number". Although it seems that
most<BR>> TrueType fonts set this element to 0, Microsoft<BR>> and Apple
platforms seem to ignore this element.<BR>> If the neglect of this element
is not essential,<BR>> I wish if the standard value is defined, or,<BR>>
described as this is not used (or renamed as<BR>> reserved).<BR>>
<BR>> In addition, I want to hear the comment from Apple, if they<BR>>
are interested in the standardization how to distinguish<BR>> the coverage
element in kern subtable. The bitwise<BR>>interpretation<BR>> of the
coverage element is incompatible between Microsoft<BR>> TrueType (and
OpenType) and Apple TrueType. If any restriction<BR>> makes it possible to
distinguish OpenType 16bit kern from<BR>> Apple TrueType 16bit kern, I wish
if it's addded in future<BR>> OpenType specification.<BR>> <BR>> It
seems that current Mac OS X automatically detects OpenType<BR>> 16bit kern
and parses it in OpenType syntax, but sometimes<BR>> the detection is
confused. I have a few commercial fonts<BR>> designed for Microsoft
Windows: they are kerned in Windows but<BR>> not kerned in Mac OS
X.<BR>> <BR>> When I and Masatake Yamato (Red Hat) implemented a
validator<BR>> of kern table, we took a heuristic algorithm in
following:<BR>> <BR>> step1:<BR>> extract 4bit from LSB of coverage
element and<BR>> interpret it as the subtable format as Apple<BR>> 16bit
kern.<BR>> <BR>> step2:<BR>> If the subtable format is 0 or 2 and
requires<BR>> the state machine of TrueType GX, the subtable<BR>> is
recognized as of Apple 16bit kern.<BR>> If it is 1 or 3, TrueType GX state
machine is<BR>> required, so the interpretation is assumed to<BR>> be
wrong - go to step 3.<BR>> <BR>> step3:<BR>> extract 8bit from MSB of
coverage element and<BR>> interpret it as the subtable format as
OpenType<BR>> 16bit kern.<BR>> <BR>> This algorithm is not perfect.
For example, the coverage<BR>> element for vertical format 0 in Apple 16bit
kern would<BR>> be 0x8000. This is same with the most popular
coverage<BR>> element in OpenType 16bit kern (horizontal format 0).<BR>>
<BR>> Regards,<BR>> mpsuzuki<BR>> <BR>> On Thu, 14 Aug 2008
16:29:21 -0400<BR>> "Levantovsky, Vladimir"<BR>><<A
href="mailto:vladimir.levantovsky%40monotypeimaging.com">vladimir.levantovsk<WBR>y@monotypeimagin<WBR>g.com</A><BR>><mailto:vladimir.<WBR>levantovsky%<WBR>40monotypeimagin<WBR>g.com>
> wrote:<BR>> >The new version of the draft has been uploaded to AHG
files<BR>>storage and<BR>> >can be downloaded using the following
link:<BR>> <BR>>><A
href="http://groups.yahoo.com/group/mpeg-OTspec/files/20080814-w10068_14496-2">http://groups.<WBR>yahoo.com/<WBR>group/mpeg-<WBR>OTspec/files/<WBR>20080814-<WBR>w10068_14496-<WBR>2</A><BR>>2<BR>><<A
href="http://groups.yahoo.com/group/mpeg-OTspec/files/20080814-w10068_14496-2">http://groups.<WBR>yahoo.com/<WBR>group/mpeg-<WBR>OTspec/files/<WBR>20080814-<WBR>w10068_14496-<WBR>2</A><BR>>2>
<BR>> >_FCD_2nd-Ed.<WBR>zip<BR>> <BR>>><<A
href="http://groups.yahoo.com/group/mpeg-OTspec/files/20080814-w10068_14496-">http://groups.<WBR>yahoo.com/<WBR>group/mpeg-<WBR>OTspec/files/<WBR>20080814-<WBR>w10068_14496-</A><BR>>2<BR>><<A
href="http://groups.yahoo.com/group/mpeg-OTspec/files/20080814-w10068_14496-2">http://groups.<WBR>yahoo.com/<WBR>group/mpeg-<WBR>OTspec/files/<WBR>20080814-<WBR>w10068_14496-<WBR>2</A><BR>>>
<BR>> >2_FCD_2nd-Ed.<WBR>zip> <BR>> ><BR>> > <BR>>
>I will be on vacation Aug. 16-30 and will not have access to<BR>>email.
I<BR>> >would like to ask you to continue the review of the FCD text
in<BR>> >preparation for our AHG meeting/teleconfere<WBR>nce on
September 8.<BR>>I will<BR>> >announce the detailed agenda for the
call as soon as I come<BR>>back from<BR>> >vacation.<BR>> >
<BR>> >Thank you,<BR>> >Vladimir<BR>> <BR>><BR>>
<BR>><BR>><BR></P></DIV><!--End group email --></BLOCKQUOTE></BODY></HTML>