Comments on ISO/IEC 14496-22 "Open Font Format"
Levantovsky, Vladimir
vladimir.levantovsky at monotype.com
Thu Feb 15 19:45:23 CET 2018
Thank you Peter!
Please see my comments inline.
From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Wednesday, February 14, 2018 9:16 PM
To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
Subject: RE: Comments on ISO/IEC 14496-22 "Open Font Format"
<snip/>
- 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.
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;
- ‘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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.microsoft.com-252Ftypography-252Fotspec-252Fbase.htm-26amp-3Bdata-3D02-257C01-257Cpetercon-2540microsoft.com-257Cb0ecad89143749431df808d5223cb66e-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636452566520551378-26amp-3Bsdata-3D7fGXGFajdaK6hDPjkJQ1cqJE8Iw0npoZnSc2cuZ-252FEw8-253D-26amp-3Breserved-3D0&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=yTYsqm8JCi6GkE0Eo0NXPBpp_jkUcz-IsGl2OGwermc&s=QoDrOlGCUZxzuNF-FXayyl4DQKp-HY781CPh1kJjIaw&e=> 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
________________________________
This email has been scanned for spam and viruses. Click here<https://us-spambrella.cloud-protect.net/index01.php?mod_id=11&mod_option=logitem&mail_id=1518660955-ZqGtE8nJxPu0&r_address=vladimir.levantovsky%40monotype.com&report=1> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20180215/096e062e/attachment.html>
More information about the mpeg-otspec
mailing list