<div dir="ltr">I suggest we *recommend* that tables start at 4byte offsets, since that makes access faster on some hardware. But otherwise no requirement at all, since all implementations have to be prepared to handle non-aligned tables.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 9:41 AM Peter Constable <<a href="mailto:pgcon6@msn.com">pgcon6@msn.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-1440227322231449747WordSection1">
<p class="MsoNormal"><span lang="EN-CA">Currently the OT spec / OFF as well as Apple’s spec are somewhat ambiguous wrt the need for top-level tables to begin at offsets that are integral multiples of four bytes.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><a href="https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html" target="_blank">Apple’s spec</a> gives the algorithm to calculate a checksum for a table, which sums 32-bit chunks. This doesn’t necessarily imply
that table lengths must be multiples of four (it could consume the first one to three bytes of a following table) except in the case of the last table in the file—there’s no allowance in the algorithm for reaching EOF before reaching the table length. But
allowing checksum for one table to count bytes from a following table would seem odd. It could alco create confusion when calculating a checksum for the file as a whole:
<i>Do overlapping bytes get counted twice?<u></u><u></u></i></span></p>
<p class="MsoNormal"><i><span lang="EN-CA"><u></u> <u></u></span></i></p>
<p class="MsoNormal"><span lang="EN-CA">The <a href="https://docs.microsoft.com/en-us/typography/opentype/spec/otff#calculating-checksums" target="_blank">
section on calculating checksums in the OT spec</a> and in OFF give the same algorithm, but add a following note:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span lang="EN-CA">“</span><span style="font-size:12pt;font-family:"Segoe UI",sans-serif;color:rgb(23,23,23);background:white">This function implies that the length of a table must be a multiple of four bytes. In fact,
a font is not considered structurally well-formed without the correct padding. All tables must begin on four-byte boundaries, and any remaining space between tables is padded with zeros. The length of all tables should be recorded in the table record with
their actual length (not their padded length).</span><span lang="EN-CA">”<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA">That seems like a clearly-stated requirement. But if four-byte alignment is a requirement, it shouldn’t be stated here as an implication of the checksum adjustment; it should be stated in the description of table records
within the table directory.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA">But then in the <a href="https://docs.microsoft.com/en-us/typography/opentype/spec/recom#table-alignment-and-length" target="_blank">
Recommendations section</a> of OT/OFF, four-byte alignment is mentioned as a _<i>recommendation</i>_, not a requirement:<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p>
<p style="margin-left:0.5in;background:white"><span lang="EN-CA" style="color:black">“</span><span style="font-size:12pt;font-family:"Segoe UI",sans-serif;color:rgb(23,23,23)">All tables should be aligned to begin at offsets which are multiples of four bytes. While
this is not required by the TrueType rasterizer, it does prevent ambiguous checksum calculations and greatly speeds table access on some processors.<u></u><u></u></span></p>
<p style="background:white;box-sizing:inherit;margin:1rem 0px 0px;outline-color:inherit;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:12pt;font-family:"Segoe UI",sans-serif;color:rgb(23,23,23)">“All tables should be recorded in the table directory with their actual length. To ensure that checksums are calculated correctly, it is suggested that tables begin on 32-bit boundaries.
Any extra space after a table (and before the next 32-bit boundary) should be padded with zeros.</span><span lang="EN-CA" style="color:black">”</span><span lang="EN-CA"><u></u><u></u></span></p>
<p style="background:white"><span lang="EN-CA" style="color:black">This is all weasel wording. Either four-byte alignment (with zero padding as needed) should be required, and the checksum calculation be stated is now—easily. Or, four-byte alignment should
not be required, but the description for calculation of checksums should be elaborated to cover edge cases unambiguously.</span><span lang="EN-CA"><u></u><u></u></span></p>
<p style="background:white"><span lang="EN-CA" style="color:black">As allowing for the edge cases adds non-trivial complication, both in the description and in implementations, I’m inclined to make it a requirement that tables begin at four-byte-multiple offsets
(and remove the weasel wording in the Recommendations section).</span><span lang="EN-CA"><u></u><u></u></span></p>
<p style="background:white"><span lang="EN-CA" style="color:black">Either way, there would be one possible edge case that should be covered: the last table in a file, and how to calculate a checksum if the table length is not a multiple of four. My inclination
would be to cover this —which would also cover the general case — by saying that, if a table length is not a multiple of four, then it must be padded with zero bytes to the next four-byte boundary.</span><span lang="EN-CA"><u></u><u></u></span></p>
<p style="background:white"><span lang="EN-CA" style="color:black">Would this break any assumptions in current runtime or tool implementations to make this a clear requirement?</span><span lang="EN-CA"><u></u><u></u></span></p>
<p style="background:white"><span lang="EN-CA"><u></u> <u></u></span></p>
<p style="background:white"><span lang="EN-CA" style="color:black">Thanks<br>
Peter</span><span lang="EN-CA"><u></u><u></u></span></p>
</div>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>