Re: CSS layout and line breaking

On Wed, 27 Feb 2013 08:02:51 +0100, Frédéric Wang wrote:

> http://ojanvafai.com/post/mathml-in-webkit

I agree with Ojan that, to get ideal layout in all situations, a
different layout algorithm is required, and his suggestion sounds
sensible to me.

Watch out though that an algorithm with complexity that is
expontential wrt depth of frame tree can get very time consuming.

On the other hand, the dependence of width on height is (usually)
small.  Perhaps the existing CSS algorithms could be adjusted a
little to better handle situations where the upper bound
calculated for width is noticeably greater than the width actually
used.

See the example at the end of this post.  IIRC there was a time
when the inline math in Gecko would have a unsightly gap after it
before the adjacent text, but this situation is handled fine now.

The table situation is currently not handled so well, but perhaps
it is possible to use a modified table layout algorithm that
better handles inconsistencies when a cell's reflowed width ends
up smaller than its previously reported minimum width.  In this
example at least, the table could adjust its size based on the
final widths of its contents.

> I remember that Karl said a long time ago that he was not happy
> with the approach with intrinsic width computation for MathML so
> I'm wondering what are the issues at the moment, apart the fact
> that for stretchy operators we are a bit overestimating the
> intrinsic width? Perhaps something with how we treat embellished
> operators? IIUC the way to fix bug 415413 would also be to
> overestimate the intrinsic width of text frames?

Bug 415413 is the most problematic imperfection at the moment, I
think.  It is about inconsistencies in the inclusion of glyph
y-direction ink overflow in y-spacing metrics.  It should be
possible to get this exactly right for unstretched characters, so
I don't think we need to add more overestimation here (except
perhaps where there may be special cases where MathML layout
doesn't include the overflow in its calculations).

> BTW, I think the fact that things like
>
> <mpadded width="height">...</mpadded>
>
> can make width depends on height is a problem with our curent
> approach but that could probably be removed from the MathML spec
> (I don't think computing horizontal metrics from vertical metrics
> is used in practice).

Yes, this adds considerable complexity to the algorithm.

> I believe that we have many issues with <math>/<mtable> frames
> inheriting from CSS frames and not our MathML ones (like bugs
> 219873, 236963 or 433064) so adding a pseudo mrow frame would
> probably be the solution. But I guess we should implement line
> breaking first, at least the most basic feature (breaking in
> <mrow> frames at <mo> positions). I don't see how we can do that
> without keeping our intrinsic width approach (and improving it to
> distinguish "min-content" and "max-content).

I think Ojan's proposal could be adjusted to layout for minimum
size and preferred size calculations.  And if mpadded's
width="height" situation is excluded, I hope layout could be done in
three root-to-leaves-to-root passes to avoid exponential complexity. 

> A trivial line breaking example is
>
>    <div style="width: 100px;">
>      <table>
>        <tr>
>           <td>
>             <math>
>               <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
> 	      <mo>+</mo>
> 	      <mi>x</mi>
>             </math>
>           </td>
>         </tr>
>      </table>
>    </div>
>
> that Gecko currently line breaks, as expected. I tested this with
> MathPlayer/MathJax linebreaking support and they are not able to
> line break the equation correctly (while they can if you remove
> the table and directly put the <math> in the <div>) probably
> because there is no interaction with the table column width. It
> seems to me that relying on the CSS model helps us to pass this
> test.
>
> Any thoughts?

Gecko's CSS line-breaking works for this example, but there are
things that are important to MathML that are not important to text
layout, such as preferring to break at certain operators,
preferring before operators to after operators, etc.

There is also considerable complexity in Gecko's CSS layout, such
as various text alignment modes and Unicode bidi inference, that
I assume is not necessary for MathML.

So I think there is justification for using MathML specific
line-breaking code.

_______________________________________________
dev-tech-mathml mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-mathml

<!DOCTYPE html>
<body>
  <math><mi>a</mi></math> is defined by the expression
  <math><mi>a</mi><mo>=</mo>
    <mstyle open="{" close="}">
    <mfenced>
      <mn>2</mn>
      <mfenced>
          <mn>2</mn><mpadded height="height"><mi>b</mi></mpadded>
      </mfenced>
      </mfenced>
    </mstyle></math> and that does not take up too much space when inline
    amongst, text but does when in an &lt;mtable&gt;:
  <math display="block">
    <mstyle open="{" close="}">
    <mfenced><mtable>
        <mtr><mtd>
    <mfenced>
      <mn>2</mn>
      <mfenced>
          <mn>2</mn><mpadded height="height"><mi>b</mi></mpadded>
      </mfenced>
      </mfenced>
        </mtd></mtr>
        <mtr><mtd>
            <mi>a</mi>
        </mtd></mtr>
    </mtable></mfenced>
    </mstyle>
  </math>
</body>
<html>