Tunneling block mode to <equation-block> breaks line in HTML output

[patrickleevers]

Working on a stylesheet to format equation-d elements for HTML, I've hit a problem which didn't show up for PDF.

In an <equation-block>, the math content should be set in 'display' style (full height) but we need to set preceding and following text/puctuation on the same line.

The org.dita-community.dita13 plugin stylesheet equation-d2html tunnels blockOrInline="block" down to MathML. At least when rendering mathML to HTML with MathJax, this inserts unwanted linebreaks before and after the equation. Only deleting the stylesheet line

    <xsl:with-param name="blockOrInline" tunnel="yes" select="'block'"/>

fixes the problem: to my surprise, the linebreaks persist even if display="block" is set only on the math element itself.

I guess a similar issue will arise with <equation-display> (which I haven't yet found a use for).

I'm using MathFlow in oXygen. A separate question is how the mathML editor will get to know that it's working within one of these block elements and set for the math element…

[drmacro]

Can you provide a sample topic that demonstrates the behavior?

[drmacro]

I created a sample like this:

<p>This is before the equation<equation-inline><mathml>
      <mathmlref
        href="../mathml/mathml-equation-01.mathml"/>
      </mathml>. After the equation. There is a period (.) immediately following the equation.</equation-inline></p>

Where the referenced math specifies display="block" on the m:math element.

The resulting HTML looks correct to me under Safari--the equation is inline but rendered full height and there is minimal space before and after it. Screen snap of the rendered HTML page is attached.

I couldn't see anything in the XSLT that would result in extra spacing in the HTML--the transform is just emitting the MathML markup to the HTML as is.

[patrickleevers]

I’m even more puzzled than I was.

Attached is a sample topic edited down to exclude cross-references. My test map (actually a bookmap) has several topics to test equation cross-referencing.

I get your result only when I change line 19 to set blockOrInline to “inline”. The generated HTML is:

drmacro commented 8 years ago

I don't see any attachment--you may need to create a gist--I think you can only attach images to issues.

drmacro commented 8 years ago

Note that my example uses equation-inline as the container for the MathML--equation-inline means "render the equation inline" and that is independent of the block/inline setting on the m:math element.

If you are using equation-block rather than equation-inline then the results you're getting are as expected--equation-block means "render this equation as a separate block out of line.

the equation block/inline distinction is independent of the MathML-specific block/inline distinction, which it needs to be since whether a MathML equation is block or inline is entirely about how the equation is rendered irrespective of any larger output context (that is, is the equation rendered as a block or as an inline).

It's this very distinction that drove that final equation-* distinctions since it became clear that blockness of the rendering of the equation container was orthogonal to the blockness of the rendered equation itself.

patrickleevers commented 8 years ago

Eliot, the attachment was there: I’ve sent it to your contrext address as your next message resolved the issue for me.

On 5 Dec 2015, at 19:08, Eliot Kimber notifications@github.com wrote:

I don't see any attachment--you may need to create a gist--I think you can only attach images to issues.

— Reply to this email directly or view it on GitHub.

patrickleevers commented 8 years ago

OK thanks, this makes sense. Thanks for clarifying it before I began to implement the new equation container elements in an awful lot of existing topics.

How has ‘displaystyle’ been set correctly to “true" on MathML whose parent is an inline container, whose parent is an equation-block?

On 5 Dec 2015, at 19:13, Eliot Kimber notifications@github.com wrote:

Note that my example uses equation-inline as the container for the MathML--equation-inline means "render the equation inline" and that is independent of the block/inline setting on the m:math element.

If you are using equation-block rather than equation-inline then the results you're getting are as expected--equation-block means "render this equation as a separate block out of line.

the equation block/inline distinction is independent of the MathML-specific block/inline distinction, which it needs to be since whether a MathML equation is block or inline is entirely about how the equation is rendered irrespective of any larger output context (that is, is the equation rendered as a block or as an inline).

It's this very distinction that drove that final equation-* distinctions since it became clear that blockness of the rendering of the equation container was orthogonal to the blockness of the rendered equation itself.

— Reply to this email directly or view it on GitHub.

drmacro commented 8 years ago

At least in my test case, the @display attribute is explicitly set on the m:math element.

It may be that the correct behavior is accidental and that I need to better understand the use case.

I think my expectation was that the author of the equation would use @display on the m:math element to control that aspect of the rendering of the MathML.

But if we need to do more to coordinate the @displayStyle attribute, perhaps by looking at the @display attribute to determine the author's intent for the equation.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[drmacro]

Note that my example uses equation-inline as the container for the MathML--equation-inline means "render the equation inline" and that is independent of the block/inline setting on the m:math element.

If you are using equation-block rather than equation-inline then the results you're getting are as expected--equation-block means "render this equation as a separate block out of line.

the equation block/inline distinction is independent of the MathML-specific block/inline distinction, which it needs to be since whether a MathML equation is block or inline is entirely about how the equation is rendered irrespective of any larger output context (that is, is the equation rendered as a block or as an inline).

It's this very distinction that drove that final equation-* distinctions since it became clear that blockness of the rendering of the equation container was orthogonal to the blockness of the rendered equation itself.

[patrickleevers]

Eliot, the attachment was there: I’ve sent it to your contrext address as your next message resolved the issue for me.

On 5 Dec 2015, at 19:08, Eliot Kimber notifications@github.com wrote:

I don't see any attachment--you may need to create a gist--I think you can only attach images to issues.

— Reply to this email directly or view it on GitHub.

[patrickleevers]

OK thanks, this makes sense. Thanks for clarifying it before I began to implement the new equation container elements in an awful lot of existing topics.

How has ‘displaystyle’ been set correctly to “true" on MathML whose parent is an inline container, whose parent is an equation-block?

On 5 Dec 2015, at 19:13, Eliot Kimber notifications@github.com wrote:

Note that my example uses equation-inline as the container for the MathML--equation-inline means "render the equation inline" and that is independent of the block/inline setting on the m:math element.

If you are using equation-block rather than equation-inline then the results you're getting are as expected--equation-block means "render this equation as a separate block out of line.

the equation block/inline distinction is independent of the MathML-specific block/inline distinction, which it needs to be since whether a MathML equation is block or inline is entirely about how the equation is rendered irrespective of any larger output context (that is, is the equation rendered as a block or as an inline).

It's this very distinction that drove that final equation-* distinctions since it became clear that blockness of the rendering of the equation container was orthogonal to the blockness of the rendered equation itself.

— Reply to this email directly or view it on GitHub.

[drmacro]

At least in my test case, the @display attribute is explicitly set on the m:math element.

It may be that the correct behavior is accidental and that I need to better understand the use case.

I think my expectation was that the author of the equation would use @display on the m:math element to control that aspect of the rendering of the MathML.

But if we need to do more to coordinate the @displayStyle attribute, perhaps by looking at the @display attribute to determine the author's intent for the equation.