[mpeg-OTspec] AHG on Open Font Format kick-off

Fri Sep 5 20:22:55 CEST 2008

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)

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> 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-22
>_FCD_2nd-Ed.zip
><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