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