32-bit glyph IDs

[PeterConstable]

It's unclear what the thinking was behind using 32-bit glyph IDs in the base glyph and layer records. (Note that v0 structures use uint16.)

• building in forward compatibility to a future in which fonts can have > 64K glyphs?
• keeping 4-byte-integral structures?
• other?

Note that this adds at least 6 bytes of padding to every colour glyph. For an emoji font, that will be an additional 12K to 20K (or more?) of padding.

(I'm not opposed, just want to understand the thinking behind proposing it, and to make sure the size implications are understood.)

[behdad]

• building in forward compatibility to a future in which fonts can have > 64K glyphs?

Yes, this was my intention.

• keeping 4-byte-integral structures?

That's a non-issue to me since everyone has to support unaligned anyway.

Note that this adds at least 6 bytes of padding to every colour glyph. For an emoji font, that will be an additional 12K to 20K (or more?) of padding.

Right. But will definitely be a tiny bit of the font size, so I'm happy to "waste" that. Compression takes care of it for any download situations as always.

[rsheeter]

We care about the size at rest (e.g. in a system image) as well as the transfer size. I suggest we use uint16. If/when we are ready to introduce 32-bit gids we should make that as a global or spec wide change, perhaps introducing COLRv2 which is just v1 with a 4-byte offset.

[anthrotype]

I agree with Rod, it feels odd to have 32-bit GlyphIDs only in COLRv1. We can always change it later and bump COLR table version.

[rsheeter]

I propose to close this issue and pickup 32 bit gids and offsets as a standalone project, likely a W3C WG spawned from the shiny new CG. I imagine the end result of that is COLR gains the ability to support 16 or 32 bit gids, compiler can choose as appropriate for the specific font. @behdad would that work for you?

[behdad]

Definitely works for me, yes. Just be more code and spec to maintain. Go ahead and close though.

[davelab6]

Reopening and filing under the "COLRv2" milestone

Also, I note that making GIDs 32-bit compatible before glyf et al are updated, was already done in CFF2, per https://lists.aau.at/pipermail/mpeg-otspec/2020-September/002369.html

[alerque]

Relevant crosslink: MPEGGroup/OpenFontFormat#10

[rsheeter]

I would like to treat 32 bit gids as a standalone thing - ideally forming a group for it, filed w3c/font-text-cg#8 - rather than scattering issues like this all over the place. Accordingly, I propose to close this (again).