[MPEG-OTSPEC] checksum / 4-byte table offset weasel wording

[Simon Cozens]

On 31/08/2020 16:41, Peter Constable wrote:
> 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.

This is another example where it's useful to have the distinction 
between what font consumers should do and what font producers should do.

CommonType puts it like this (I'm sorry if you're already fed up of 
hearing that phrase; please get used to it):


2.1.3.1. Implementation notes for font producers

* Tables must aligned to a four byte boundary.

* Table lengths must be a multiple of four bytes. Zero padding should be 
added to the end to make up an integral multiple if necessary.

* Table checksums are computed using the following checksum algorithm 
(in Python):

def calcChecksum(table):
     # Zero-pad table to four-byte boundary
     while len(table) % 4 > 0:
         table += b"\0"

     # Calculate the unsigned sum of all four-byte values
     value = 0
     for i in range(0, len(table), 4):
         long = struct.unpack(">L", table[i:i+4])
         value = (value + long) & 0xffffffff
     return value

[...]

2.1.3.2. Implementation notes for font consumers

* When validating table checksums, the head table must be treated as a 
special case, and its checkSumAdjustment value set to four zero bytes 
for the purposes of checksumming. Font consumers should not assume that 
the table length will be a multiple of four, and should use the above 
checksumming algorithm which adds zero padding to the table data.

S