Wait. My measurement might be flawed.

In my testing with NotoColorEmoji-Regular, it saved a meager 824 bytes. Still, it's the right thing to do.

The BaseGlyphList must be sorted by glyphID to be able to do the binary search, remember?

https://learn.microsoft.com/en-us/typography/opentype/spec/colr#baseglyph-and-layer-records

The BaseGlyph records must be sorted in increasing glyphID order. It is assumed that a binary search can be used to find a matching BaseGlyph record for a specific glyphID.

If you really want to build the LayerList in that decreasing length order, you can do that but then you need to make sure that the baseGlyphs are sorted by glyphOrder at the end

You are right. I'll fix up.

@anthrotype PTAL.

would also be nice to have a test that exercise this if not much trouble

would also be nice to have a test that exercise this if not much trouble

Good thing I did. Implementation was wrong. Building noto color emoji now to get new numbers.

Need to update test expectations now.

@anthrotype PTAL again. Sorry about that earlier.

Humm. I don't see this making any difference in NotoColorEmoji. Investigating.

Humm. I don't see this making any difference in NotoColorEmoji. Investigating.

I fixed the culprit. However, now the font grows by a few hundred bytes. Maybe status quo is good enough.