You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use MathGlyphVariantRecord.advanceMeasurement and GlyphAssembly.partRecords[PartIndex].fullAdvance when measuring along the stretch axis.
Use advance width and (ink) ascent/descent in the orthogonal direction of the stretch axis or when measuring the base glyph (this includes the case of preferred inline size since that's done for stretching along the block direction).
I believe for the base glyph and size variants, using advance width and ink ascent/descent is consistent with normal text. And hopefully fonts are designed such that the advance width of horizontal operators match the ink width.
For stretching glyph assembly along the block axis, I believe using the advance width is necessary to ensure correct alignment of parts.
For stretching glyph assembly along the inline axis, the alignment is ensured by aligning the glyph baselines. So using ink ascent/descent will work and this is consistent with normal math text.
Note: I think for performance using advance width or reading advance in the MATH table is faster than calculating the ink bounding box (although that's maybe not relevant if you need to do it anyway for the remaining metrics).
The text was updated successfully, but these errors were encountered:
Currently, the core spec says to
I believe for the base glyph and size variants, using advance width and ink ascent/descent is consistent with normal text. And hopefully fonts are designed such that the advance width of horizontal operators match the ink width.
For stretching glyph assembly along the block axis, I believe using the advance width is necessary to ensure correct alignment of parts.
For stretching glyph assembly along the inline axis, the alignment is ensured by aligning the glyph baselines. So using ink ascent/descent will work and this is consistent with normal math text.
Note: I think for performance using advance width or reading advance in the MATH table is faster than calculating the ink bounding box (although that's maybe not relevant if you need to do it anyway for the remaining metrics).
The text was updated successfully, but these errors were encountered: