review operators stretching along the inline axis

[fred-wang]

See https://w3c.github.io/mathml-core/#stretchy-operator-axis

For example ⥦ U+2966 LEFTWARDS HARPOON WITH BARB UP ABOVE RIGHTWARDS HARPOON WITH BARB UP is missing but I'm sure many more are.

[davidcarlisle]

Hmm unicode.xml has an operator dictionary entry for that saying it's stretchy but it doesn't distinguish horizontal or vertical stretch, and the unicode MathClass-15.txt doesn't help either. Probably I should extend the schema used by unicode.xml to allow h/v stretch distinction then we just have to print off the list of characters and decide in each case (or could we get a useful list out of the Opentype tables in say Stix two math rather than doing this by eye?

[fred-wang]

yes, probably we could include in unicode.xml

The idea is that there is not a lot of horizontal-only characters so it should not be that big to check.
We ignore "Diagonal" operators since the concept does not exist in MathML Core or OpenType MATH.

We can also rely on STIX Two by checking the horiz/vert contructions in the MATH.MathVariant table ; note however, that MATH fonts use combining code point for accents.

I suspect the original list was generated from the "direction:vertical" or "direction:horizontal" of https://searchfox.org/mozilla-central/source/layout/mathml/mathfont.properties

[fred-wang]

I added more code points, but that doubled the size of the table!

https://w3c.github.io/mathml-core/#stretchy-operator-axis

Stretch axis of some operators is not clear for some code point e.g.
⮠ U+2BA0 DOWNWARDS TRIANGLE-HEADED ARROW WITH LONG TIP LEFTWARDS
⤴ U+2934 ARROW POINTING RIGHTWARDS THEN CURVING UPWARDS

Compare with this one, which is not stretchy:
⮰ U+2BB0 RIBBON ARROW DOWN LEFT

I'm considering an alternative approach here:
#106

[NSoiffer]

It seems I like #106 resolved this.

@fred-wang can you confirm this is resolved and close the issue if it is resolved?

[fred-wang]

I guess this is solved.