Vertical stretchy rule: Explicit calculation for minsize/maxsize constraints?

[fred-wang]

For minsize/maxsize, MathML 3 says "increase or decrease both height and depth proportionately so that the effective size meets the constraint".

I think proportionately means multiply the same scale factor (minsize / (height + depth) or
maxsize / (height + depth)). This is what Gecko and WebKit do.

Alternatively, one could do
delta = minsize - (height + depth)
height += delta/2
depth += delta / 2 (or even depth = minsize - height)

which has the advantage to not explicitly use float conversion (browsers used fractional pixels for layout, which are internally integers). In WebKit relative maxsize / minsize are converted to fractional pixels before use.

[fred-wang]

In WebKit relative maxsize / minsize are converted to fractional pixels before use.

I guess WebKit is wrong here. You need to multiply by the target size by the % during stretching.

[fred-wang]

Current definition is https://mathml-refresh.github.io/mathml-core/#algorithm-for-stretching-operators-along-the-block-axis There is a special case when the target size is 0.

[fred-wang]

From 2019/11/11: postponed so that people can check again.

[NSoiffer]

I checked to see what MathPlayer does and it scales (multiples) the values. As is done in the spec, this happens after symmetric adjustments are made.

One thing I noted in the MathPlayer implementation that needs to be thought about is rounding. After scaling the height, MathPlayer calculates the depth something like:
depth = minsize - height
to make sure that the total height is the desired height and not affected by truncation when converted to an integer.

The spec appears to be silent about whether the layout calculations should be considered high precision arithmetic or integer (or fixed-point) calculations. If the latter, we need to be careful rounding/truncation in the layout algorithms. I don't know what CSS says about this for its layout algorithms, but that is almost certainly what we should do in the core spec.

[NSoiffer]

From the 18/11/19 meeting, the resolution was to use scaling and to avoid rounding by assigning to the descent the remaining amount from the target size after scaling the ascent. I.e.,

ascent = ascent* minsize / (ascent + descent)
descent = minsize - ascent
(equivalently, using maxize)

This avoids problems caused by rounding so that the new ascent+descent == minsize (e..g, if minsize is half of ascent+descent, you essentially have division by two and if using integers or fixed point arithmetic, potentially there is a rounding problem.

There was also discussion that we should do what CSS does, so someone needs to double check with a CSS expert to see if they faced the same issue.

[fred-wang]

I think Bruce suggested to split the error symmetrically, so that would be:

ascent = ascent * minsize / (ascent + descent)
descent = descent * minsize / (ascent + descent)
ascent += (minsize - (ascent + descent)) / 2
descent = minsize - ascent

but not sure how different it would be.

[fred-wang]

I removed the "need tests" flag, as it will likely be difficult to reproduce this rounding errors and at the same time avoiding flaky tests.