Re-implement stretchy math operators using composed shapes

[alerque]

sile/packages/math/base-elements.lua

Lines 1133 to 1137 in 21bcc5c

	-- HACK: For stretchy operators, MathML Core and OpenType define how to build large glyphs
	-- from an assembly of smaller ones. It's fairly complex and idealistic...
	-- Anyhow, we do not have that yet, so we just stretch the glyph artificially.
	-- There are cases where this will not look very good.
	-- Call that a compromise, so that long vectors or large matrices look "decent" without assembly.

HACK: For stretchy operators, MathML Core and OpenType define how to build large glyphs from an assembly of smaller ones. It's fairly complex and idealistic... Anyhow, we do not have that yet, so we just stretch the glyph artificially. There are cases where this will not look very good. Call that a compromise, so that long vectors or large matrices look "decent" without assembly.

[Omikhleia]

Concerns:

• Handling of vertical stretchy operators ("along the block axis")
• Handling of horizontal stretchy operators ("along the inline axis")
• Root symbols (msqrt / mroot) on both axis

Aside note: Even glyph assembly can lead to sizes being off, so re-scaling with a PDF matrix is not necessarily entirely out of the picture -- but the closer we are to the target size, the less scaling artifacts are visible.

[Omikhleia]

Aside note: Old typographers (from the time characters were in "metal"), well usually, did do this kind of insane glyph assembly logic.¹ It's not because a technology exists that it has to be used. 🐰

Footnotes

1. Most of the time, they reserved the space with rectangular shapes (or "struts"), and would have another person applying ink pads (usually wooden cuts) over the printed text. Same often applied to dropped capitals. ↩

[khaledhosny]

Asymmetrical scaling can (and will) distort glyph shapes, and symmetrical scaling will make the glyphs out of proportion. There a reason the MATH table has glyph assemblies and that is not lack of scaling support in graphics libraries. A better replacement to glyph assemblies would be font variations in MATH table (harfbuzz/boring-expansion-spec#136), but we don’t have that yet.

[Omikhleia]

... scaling can (and will) distort glyph shapes

Of course it will, and I as said, it's very noticeable when we are far from the expected size. As I wrote both in-code and in the commit log, "there are cases where this will not look very good". But what do you prefer:

• Math support that doesn't have stretchy vectors/matrices etc. --> I'm confident no one will use it.
• Math support that supports them decently although some look bad (see pic. in wip(math): Accents in math #2156 for instance) --> I believe it's more important to reach that status first (= the MathML engine at least does what it has to do up to that point).

[khaledhosny]

I was specifically commenting on this part:

Aside note: Even glyph assembly can lead to sizes being off, so re-scaling with a PDF matrix is not necessarily entirely out of the picture

I advise against doing any scaling once glyph assembly support is in place.