italic correction in mrow-like elements

[fred-wang]

Italic correction of an element should be preserved when wrapping into an [mrow-like elements]( https://mathml-refresh.github.io/mathml-core/#dfn-mrow-like-elements] so that for example

<math display="block"><msub><mo>∫</mo><mi>x</mi></msub></math>

renders the same as

<math display="block"><msub><mrow><mo>∫</mo></mrow><mi>x</mi></msub></math>

[fred-wang]

A simple extension that I implemented in chromium is it use the italic correction of the last in-flow child (rather than checking whether there is exactly one in-flow child) although that might give weird result if mrow allows linebreaking in the future

[NSoiffer]

Seems like what you want is to define slanted to be recursive, much as is done for embellished operators. The current definition is

A child box is slanted if it is not an embellished operator and has nonzero italic correction.

A recursive definition would be:

A child box is slanted if:

1. It is a token element other than mo and it has a non-zero italic correction
2. It is an mrow element whose last in-flow element is slanted.

Since some token elements such as mspace will never have a non-zero italic correction, there may be a better choice than to use the words "token element". E.g., 'an element whose display is the same as mtext' (I'm sure there is a better way to say that!).

Note: while this may seem to be introducing a recursive definition of "slanted", the previous definition is recursive because "embellished operator" is a recursive definition.

[fred-wang]

No, I don't want to change the definition of slanted. This is just a local convenient definition for mrow layout.

What I want is to define italic correction for all elements https://mathml-refresh.github.io/mathml-core/#dfn-italic-correction ; currently it's 0 by default except of "token elements" (For stretchy/largeop mo the spec lacks italic correction but it's already tested, see #197).

So we just need to decide for each layout algo how to calculate the italic correction for the "content box" ; and then how to deduce it for the margin box as per https://mathml-refresh.github.io/mathml-core/#layout-algorithms

At minimum, it seems we need to define italic correction for tokens, for stretchy/largeop mo ( #197 ), for mrow (this issue), and with padding/border/margin ( https://github.com/mathml-refresh/mathml/issues/194 ).

[NSoiffer]

In TeX, only characters have italic correction. That is used in the rules for placing accents, limits, and scripts. It is also used for horizontal layout. However, AFAIK, once used, the resulting box no longer has an italic correction. E.g., after dealing with the placement of scripts, the result becomes a vbox and that does not have an italic correction. Hence, I don't see a need to define italic correction on all boxes unless it simplifies the description of the layout algorithms (see below).

Unless there some other complexity in MathML that I'm missing, italic correction need only be defined for tokens (which large ops are a special case of). For padding/border/margin ( #194 ), that's something to think about how they should affect the italic correction. To me, that seems like something that affects the definition of the italic correction for a token, not something that creates a need for expanding the definition of italic correction.

For mrows, we need an easy conceptual way of finding that italic correction. One way is the definition of slant I gave above. Another way would be to define it for each box. It would be zero for most, but for mrow it would be defined as the italic correction of the rightmost child. So I agree with your "at minimum" statement (more or less).

The alternative definition style (i.e., defining something for all boxes) could be useful for other properties such as lspace/rspace. Again, it would be 0 for most boxes, but for mrow, its lspace would be the lspace of the first child and the rspace would the rspace of the last child. There's a bug in the current mrow layout algorithm (I'm in the process of writing it up and coming up with an alternative), but this kind of definition would make my new proposed algorithm very easy to specify.

[fred-wang]

When doing the layout of

<msub><mrow><mrow><mrow><mo>∫</mo></mrow></mrow></mrow><mn>2</mn></msub>

msub should only know about the layout result of the its children (in LayoutNG and CSS layout model at least) so grabbing the italic correction (or any other metrics) down to the inner mo is bad. That's why it is very important to define it that way in MathML Core. So again please don't spend time redefining slant this will be counter-productive. We should focus on how italic correction is passed for each algorithm instead (in most case it is already defined to be 0, we only need to add missing one for largeop/stretchy mo and mrow-like).

In general for embellished operator we have to get properties down to the inner mo and handle all the space-like-ness. That sucks and I'm not sure that will pass review, as I said in my (failed) attempt to simplify embellished operator in another issue. However, all these properties are obtained by browsing the DOM-tree only, not the layout tree (and we resolved the lspace/rspace with respect to the style of the current node, not the inner mo) so that might be ok. I wouldn't recommend to spend time on changing this for now, #176 is a much higher priority.

[fred-wang]

A simple extension that I implemented in chromium is it use the italic correction of the last in-flow child

text of the spec modified accordingly.

I'm closing this as this is a minor change and we need to write more tests for italic corrections anyway.