Re: Clarification on the size of overlapSimpleBitmap [WOFF2]

I figured it might be related to alignment. The problem though is there is
no guarantee that the transformed glyf table starts aligned (only the
metadata table is required to be 4 byte aligned). So there's no alignment
guarantee for any of the fields in the table. That and before bboxBitmap
field there are several variable length fields that don't have
alignment padding. So even if glyf starts aligned there's no
guarantee bboxBitmap starts aligned.

For now I'll stick with my current sizing assumption at ceil(numGlyphs/8)
unless there's a compelling reason not to do so.

On Mon, Mar 28, 2022 at 11:15 AM Vladimir Levantovsky <
vladimir.levantovsky@gmail.com> wrote:

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