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

[Peter Constable]

Apologies for slow response. I’ve given my take on some the comments you received — inserted inline below. I’ll respond with more shortly.


Peter



From: mpeg-OTspec at yahoogroups.com <mpeg-OTspec at yahoogroups.com> On Behalf Of 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec]
Sent: Thursday, November 2, 2017 2:57 PM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Comments on ISO/IEC 14496-22 "Open Font Format"


Dear AHG members,

I received an annotated copy of the 3rd edition OFF text with user comments. While few of those comments are irrelevant, and many comments have already been addressed in the 4th edition text, some of them do need to be considered for further discussion. Upon reviewing the comments and the text I also came up with few additional questions; among them:

-          Question about clarifying version numbers encoded in Fixed format, in particular about providing an example of how e.g. version 1.11 should be encoded;

[PC] I think an example is not needed. In the OT spec, I only kept some tables as using Fixed for version rather than uint16 major / uint16 minor because they had existing versions that were anomalous. For OT v.next, I’ll add some wording to clarify that Fixed is only used for legacy reasons, and that it will not be used for any new tables introduced in the future. Here’s my proposed text for the paragraph after the bulleted list:

“Only certain tables use a Fixed value for version, and only for reasons of backward compatibility. Fixed values will not be used in the future for any new tables that may be introduced. When a Fixed number is used as a version, the upper 16 bits comprise a major version number, and the lower 16 bits a minor version. The representation of a non-zero minor version, however, is not consistent with the normal treatment of Fixed values, in which the lower 16 bits represent a fractional value, N * 2 ^ -16. Rather, tables with non-zero minor version numbers always specify the literal value of the version number. For example, the version number of 'maxp' table version 0.5 is 0x00005000, and that of 'vhea' table version 1.1 is 0x00011000. When Fixed is indicated as the type for a version field, the possible values should be treated as an enumeration of specific values, rather than as a numeric value capable of representing many potential major and minor versions. ”



-          Question about the normative scope of uint16 version numbers, and whether the requirement to treat it as a minor version number (and consider all format changes as compatible extensions) should be considered as a mandate or as a recommendation (as it is now defined as “should”);

[PC] I can see that the current text could be seen as a bit unclear regarding single uint16 version fields. The same would also apply to single uint32 version fields. For OT v.next, my plan will be to replace the 4th paragraph after the bulleted list with the following two paragraphs:

“Minor version number changes always imply format changes that are compatible extensions. If an implementation understands a major version number, then it can safely proceed reading the table. If the minor version is greater than the latest version recognized by the implementation, then the extension fields will be undetectable to the implementation.

For purposes of compatibility, version numbers that are represented using a single uint16 or uint32 value are treated like a minor version number, and any format changes are compatible extensions. ”

.

-          In “Calculating checksums” section – [editorial] suggestion to replace “the hex value B1B0AFBA” with 0XB1B0AFBA;

[PC] I’ll use a slight modification, to be consistent with how other hex values are presented in the spec:

“Subtract that value from value 0xB1B0AFBA.”

-          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 impelemenations.”

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

-          ‘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?

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

-          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.

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

-          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 https://www.microsoft.com/typography/otspec/base.htm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Ftypography%2Fotspec%2Fbase.htm&data=02%7C01%7Cpetercon%40microsoft.com%7Cb0ecad89143749431df808d5223cb66e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636452566520551378&sdata=7fGXGFajdaK6hDPjkJQ1cqJE8Iw0npoZnSc2cuZ%2FEw8%3D&reserved=0> 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.

-          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.

Thank you,
Vladimir



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20180215/5e39a829/attachment.html>