RE: Clarification on the size of overlapSimpleBitmap [WOFF2]

Good catch!

 

IIRC, the size of the bboxBitmap[] was defined to be a multiple of 4 bytes to keep data fields in the transformed ‘glyf’ table word-aligned. As far as the new overlapSimpleBitmap[] is concerned, it is _now_ the last data array of the table, and I don’t think it matters where it ends – as far as implementations and functionality is concerned, padding this bit array to 4 bytes boundary won’t change anything, and sizing it at ceil(numGlyphs/8) would work just fine. 

 

The thing we do need to check is the alignment of the beginning of the overlapSimpleBitmap. The instructionStream[] is defined as a stream of UInt8 values, and its size (with the data stream being the last array of the table) wasn’t padded to word boundary. I am not sure if this padding is necessary, but if it is, this is something we might need to fix.

 

Thanks,

Vlad

 

 

From: Garret Rieger [mailto:grieger@google.com] 
Sent: Wednesday, March 16, 2022 8:00 PM
To: w3c-webfonts-wg (public-webfonts-wg@w3.org) <public-webfonts-wg@w3.org>
Subject: Clarification on the size of overlapSimpleBitmap [WOFF2]

 

I'm in the process of implementing support for the new overlapSimpleBitmap field in the woff2 encoder and decoder. The current text is potentially underspecified on what size the array should be. The following text is provided (from https://www.w3.org/TR/WOFF2/#glyf_table_format):

"A numGlyphs-long bit array that provides values for the overlap flag [bit 6] for each simple glyph. (Flag values for composite glyphs are already encoded as part of the compositeStream[])."

However the other bitmap array, bboxBitmap which has similar text, but later has a sentence that explicitly defines the size:

"The total number of bytes in bboxBitmap is equal to 4 * floor((numGlyphs + 31) / 32)"

 

This effectively sets the size of the bbboxBitmap to be multiples of 4 bytes, even though only ceil(numGlyphs/8) bytes are actually needed (I'm curious if anyone knows the reason why this is sized to multiples of 4?)

 

My interpretation of the current text is that overlapSimpleBitmap should be sized to ceil(numGlyphs/8) and not (4 * floor((numGlyphs + 31) / 32)) like bboxBitmap, but I wonder if we should make that more explicit? There's potential for confusion if an implementer uses the same sizing rules from bboxBitmap when implementing overlapSimpleBitmap.

 

Thoughts?