Comments on ISO/IEC 14496-22 "Open Font Format"

Peter Constable petercon at
Thu Feb 15 23:36:45 CET 2018

From: Levantovsky, Vladimir <Vladimir.Levantovsky at>
Sent: Thursday, February 15, 2018 10:45 AM
To: Peter Constable <petercon at>; mpeg-OTspec at
Subject: RE: Comments on ISO/IEC 14496-22 "Open Font Format"

Thank you Peter!
Please see my comments inline.

From: Peter Constable [mailto:petercon at]
Sent: Wednesday, February 14, 2018 9:16 PM
To: Levantovsky, Vladimir; mpeg-OTspec at<mailto:mpeg-OTspec at>
Subject: RE: Comments on ISO/IEC 14496-22 "Open Font Format"


-          Definition of lineGap in ‘hhea’ table – question on whether historical references to Win 3.1 and MacOS 6 and 7 still need to be preserved;

[PC] Is there particular benefit from removing those details? A partial accommodation would be to say, “Negative lineGap values are treated as zero in some legacy platform implementations.”

[VL] I suspect that for folks who graduated from college in 200x or later the references to Win 3.1 and MacOS 6 & 7 do not make much sense, I do like the alternative wording you proposed.

[PC] Fine, I’ll use the revised text above in OT (Note the spelling change “lineGap”, not “LineGap”.)

I’d also appreciate your thoughts on the remaining comments below.

-          Definition of maxStackElements in ‘maxp’ table – question about using a footnote instead of simply including it as part of the description;

[PC] Sure. I propose removal of the footnote after the tame, and this description for maxStackElements:

“Maximum stack depth across Font Program ('fpgm' table), CVT Program ('prep' table) and all glyph instructions (in the 'glyf' table).”

-          ‘kern’ table, Format 0 – the description states that it is the only format (!) that will be properly interpreted by Windows and OS/2 – do we still need to state this?

[PC] The reference to OS/2 is certainly anachronistic, but the statement still applies to Windows. For OT, I’ll revise the sentence as follows:

“This is the only subtable format supported by Windows.”

-          LookupFlag Bit enumeration table – the first table column should probably have title “Value” instead of “Type”

[PC] I assume this is referring to the OTL Common Table Formats. For tables describing flag bits, the column heading should be “Mask”, not “Value” (and, of course, not “Type”). For OT, I’ll make this change in the OTL CTF chapter.

Also, in the OS/2 chapter (v0 – v4), “Bit Mask” is used in the heading for the table in the fsType section; for better editorial consistency, I’ll change these to “Mask”.

-          GPOS table description – many table headers have “Value / Type / Description” columns, which is incorrect and should be revised to match other table definitions using “Type / Name / Description” format.

[PC] (Ugh!) Yes, of course. There were a few tables that were already correct, so a total of 39 table headings to be corrected.

-          GPOS Example 5 – needs review as I suspect Class2Count field has redundant comments.

[PC] For OT, I’ll revise rows 9, 10 and 11 in the table for Example 5 as follows:




First Class1Record, for contexts beginning with class 0


First Class2Record for class1Records[0]; valueFormat2 is zero, so no valueRecord2.

-          General comment: there are quite a few figures used in the OT/OFF text that show text rendered in low quality, low resolution bitmaps (e.g., see first three sections of<> and many other figures including illustrations for GSUB/GPOS/JSTF tables). Maybe it is the time to redo them – will need a lot of work but it’s a bit awkward when a document describing font format for high-quality text rendering uses low-res, low quality images as illustrations.

[PC] There’s enough in progress; I would leave this for future consideration.

-          Recommendations: It may be a good time reconsider parts of the “Recommendation” section as some of them seem to be requirements (e.g. Big Endian byte ordering, table alignment, etc.) and some of them (e.g. device resolutions) may be outdated and no longer relevant.

[PC] There’s enough in progress; I would leave this for future consideration.

Thank you,


This email has been scanned for spam and viruses. Click here<> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mpeg-otspec mailing list