Font metrics of composite glyphs with USE_MY_METRICS

[myang-apryse]

I found a really obscure problem and I don't know if it should be considered a vera bug.
I can't share the file, but I can provide more details for a reconstruction as needed.

I found a weird discrepancy where we disagreed with vera on the consistency of
glyph width information stored in the Widths array information vs the embedded font program.

After digging, it seems that vera was getting the horizontal advance from the HMTX table
https://github.com/veraPDF/veraPDF-parser/blob/b1aa3997093914ca7fd22a44ced669e690de9170/src/main/java/org/verapdf/pd/font/truetype/TrueTypeHmtxTable.java#L52,

which is correct under normal circumstances.

However, for my particular case, we ran into a glyph that was

1. a composite TrueType glyph
2. the subglyph (e.g. O in Ö) set the USE_MY_METRICS flag
3. the horizontal advance of the subglyph disagreed with the parent glyph

We were using FreeType, and it respected the flag, returning an advance-width that was smaller.
(e.g. 1496 taken from the O inside Ö instead of 1524 for the overall glyph).
see https://github.com/marmalade/Freetype/blob/9ee6a9e204eceffe7ff03ea7c49dd6e2dc90d8b4/src/truetype/ttgload.c#L1567

The question is, is it more semantically correct to check for consistency against the HMTX entry of the overall glyph?
Or is it better to recurse into the subglyph that has set the USE_MY_METRICS flag?

My personal inclination is that FreeType is correct here, and that vera is missing steps to correctly process these specific composite glyphs.

[bdoubrov]

@myang-apryse thanks a lot! Your (and FreeType) logic of calculating glyph widths for composite glyphs looks plausible. We'd like to check this in more detail, also looking at other implementations.