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
Another thing we might revise is the case T ≤ 0. In practice this is really T = 0 and happens when all non-stretchy siblings have zero height/depth or that we try to determine unstretched sizes when the mrow only contains stretchy elements as shown in the testcase below. The scaling adjustment cannot be performed (division by zero) and it was probably just an edge case (does not happen in practice) so the default choice to set symmetric minsize/2 above and below the baseline (math axis with the latest fix) is fine. However, Firefox/WebKit don't seem to do that when the operator does not have the symmetric property.
I'm thinking we could instead to do something like this:
If the operator has the symmetric property then continue to set the Tascent
to minsize / 2 + AxisHeight and Tdescent to minsize − Tascent.
Otherwise (if the operator does not have the symmetric property), set Tascent / Tdescent to the ascent/descent of the unstretched glyph, scaled proportionately to meet the minsize i.e. Tascent = glyphascent * minsize / glyphheight and Tdescent = minsize - Tascent.
In particular, when minsize is the default 100% and the operator does not have the symmetric property, then Tascent/Tdescent would just be the ascent/descent of the unstretched glyphs, so that unstretched glyph can just be used to render the stretched operator. Also Δ = 0 in step 6 and the unstretched glyph preserves its vertical alignment with respect to the baseline.
That said, I'm not even sure about the desired vertical alignment for operators and stretched glyph selection, even when there is only one non-stretchy element. See #205 (comment) for a testcase.
Extracting from #103
Another thing we might revise is the case
T ≤ 0. In practice this is reallyT = 0and happens when all non-stretchy siblings have zero height/depth or that we try to determine unstretched sizes when the mrow only contains stretchy elements as shown in the testcase below. The scaling adjustment cannot be performed (division by zero) and it was probably just an edge case (does not happen in practice) so the default choice to set symmetric minsize/2 above and below the baseline (math axis with the latest fix) is fine. However, Firefox/WebKit don't seem to do that when the operator does not have the symmetric property.I'm thinking we could instead to do something like this:
to minsize / 2 + AxisHeight and Tdescent to minsize − Tascent.
In particular, when minsize is the default 100% and the operator does not have the symmetric property, then Tascent/Tdescent would just be the ascent/descent of the unstretched glyphs, so that unstretched glyph can just be used to render the stretched operator. Also Δ = 0 in step 6 and the unstretched glyph preserves its vertical alignment with respect to the baseline.
That said, I'm not even sure about the desired vertical alignment for operators and stretched glyph selection, even when there is only one non-stretchy element. See #205 (comment) for a testcase.
The text was updated successfully, but these errors were encountered: