CSS layout and line breaking

[Frédéric Wang]

Hi,

I don't know if everybody saw this:

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

Currently, our MathML code has its own frames but we follow the CSS
model and compute the "min-content" and "max-content" measures (although
at the moment they are just equal for MathML). We also reuse the CSS
frames for the <math> and <mtable>/<mtr>/<mtd> elements and in
particular this provides line breaking for these elements.

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?

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).

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).

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?

--
Frédéric Wang maths-informatique-jeux.com/blog/frederic

[Karl Tomlinson]

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.

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.

[David Carlisle]

On 04/03/2013 06:37, Karl Tomlinson wrote:
>> <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.
>

In some layout systems (TeX for example) this is no complexity at all
and is exactly the same as accessing the width, similarly in the spec it
just fell out naturally by giving all "length" based attributes the same
syntax.

That said, it is I would guess, never used in real documents other
than test files. It really is not worth adding any complexity to support
this. I don't think there is any issue really once the gecko and webkit
implementations have shaken out what works and what doesn't work so well
in a css/browser based context that we publish some kind of note or
profile or whatever detailing any darker corners like this. Whether you
should ignore width="height" or (perhaps better just say height means
"current baseline spacing" or something) could be decided later.


David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

[Karl Tomlinson]

David Carlisle writes:

> On 04/03/2013 06:37, Karl Tomlinson wrote:
>>> <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.
>>
>
> In some layout systems (TeX for example) this is no complexity at all
> and is exactly the same as accessing the width, similarly in the spec it
> just fell out naturally by giving all "length" based attributes the same
> syntax.
>
> That said, it is I would guess, never used in real documents other
> than test files.

If it is used somewhere, I guess Ojan's algorithm could work if we
just did no automatic line breaking of descendants of mpadded.

I haven't studied the layout algorithm of TeX. When I used TeX, I
think I only noticed automatic line-breaking for text paragraphs,
and used manual line breaks for equations.

[David Carlisle]

On 05/03/2013 04:14, Karl Tomlinson wrote:
> I haven't studied the layout algorithm of TeX. When I used TeX, I
> think I only noticed automatic line-breaking for text paragraphs, and
> used manual line breaks for equations.

That is TeX's algorithm:-)


However you can program automatic linebreaking _in_ TeX macros (just as
the float placement algrithm is something programmed in tex macros not
provided in the tex executable). What I meant was that in TeX to
measure _any_ attribute of a sub-expression then you need to box it
(or a temporary copy of it) and then you have height, depth and width
available, so setting the padded width to be a function of the natural
height is conceptually, and in any TeX implementation, no harder than
setting the padded width to be a function of the natural width.

[William F Hammond]

FWIW

From my earliest days using LaTeX I have always thought that
any line breaks in math should be placed deliberately by the
author. It's a matter of good editorial policy. [Of
course, Gresham's law tells us that bad taste drives out
good. :-) ]

As a consequence, for <math> in mathml I use the css:

math {white-space: nowrap}

Beyond taste there is the matter that I want to think of
(even presentation) <math> content as grist for a computer
algebra system where line breaks have no roll as
mathematical content.

-- Bill