[tex4ht] dbmlatex conversion...

[Zdzislaw Meglicki]

Indeed, I have noticed, experimenting with it some more, that the Java script 
that's used by the dbmlatex mode (also oolatex) is paranoid about unmatched 
parentheses within a row (<mrow> ... </mrow>), which is what triggers the error. 

And... I even used it to debug my own complicated input, where missing brackets 
were found in some formulas by the script.

Still, I think, this can't be quite right. 

For starters, running

htlatex file.tex "xhtml,mathml" " -cunihtf"

generates xhtml with mathml, and... the problem does not arise. Furthermore, 
Tralics and LaTeXML, which also generate XML on output, have no problem with 
this construct. Last, but not least, we do have the need in mathematics to 
sometimes split formulae like this over multiple lines, so the requirement that 
parentheses must match within a single row is too strong. We even have the need 
to not match parentheses at all sometimes. For example, we may wish to discuss a 

fragment of a formula in text, a fragment that would contain only the opening 
(or only the closing) parentheses of a larger formula. 


There must be some MathML way for doing this. For example, you may start an 
<mrow> then simply insert carriage returns <cr> into the formula before closing 
it with </mrow>. So, it would be a multiline <mrow>, which is what, 
semantically, a \begin{split} ... \end{split} construct is.

Now, TeX and LaTeX are not as forgiving in this context either. For example, you 

cannot split within \left( ... \right). But you can, if you replace \left( ... 
\right) with an explicit bracket, e.g., \Bigl( ... \Bigr). So, similarly, isn't 
there a construct in MathML for a bracket that does not need to be matched?

Zdzislaw (Gustav) Meglicki
Indiana University
http://perth.ovpit.indiana.edu/gustav




----- Original Message ----
From: CV Radhakrishnan <cvr at river-valley.org>
To: tex4ht at tug.org
Sent: Wed, October 24, 2012 3:09:18 AM
Subject: Re: [tex4ht] dbmlatex conversion...

On 10/23/12 23:30, Zdzislaw Meglicki wrote:
> Absolutely stripped of everything non-essential. Here's the example (sorry, I 
> should have done this before).

Many thanks for this.

> \begin{eqnarray*}
> a &=& ( A \\ 
> &&\quad -\, B )
> \end{eqnarray*}

Although, this is legal in TeX world, tex4ht won't generate right kind
of MathML. In other words, MathML generated will not be passed by
parsers. Hence, conversions that rely on MathML will not be
successful. oolatex, dblatex, etc do want parsable MathML from your
TeX math. Given below is the MathML generated by TeX4ht with dummy
elements added to make it parsable.

<mtable class="eqnarray-star"
columnalign="right center left">
<mtr>
<mtd class="eqnarray-1">
<mi>a</mi>
</mtd>
<mtd class="eqnarray-2">
<mo class="MathClass-rel">=</mo>
</mtd>

Each opening delimiter starts with <mrow> followed by the delimiter
which makes the tagging scheme look like: <mrow><mo>(</mo> followed by
elements for subsequent math atoms. In the same fashion, each closing
delimiter ends with a closing </mrow> which will look like
<mo>)</mo></morw>. Therefore, when there is no ")", we miss a closing
</mrow> element. In the same vein, we lose an opening <mrow> when
there is no opening parenthesis. Improperly nested elements disrupt
XML rules and leaves it unusable.

<mtd class="eqnarray-3">
<mrow> <!-- this has no closing element-->
<mo class="MathClass-open">(</mo>
<mrow>
<mi>A</mi>
</mrow>
</mrow> <!-- dummy element added manually-->
</mtd>
<mtd class="eqnarray-4">
<mtext class="eqnarray"></mtext>
</mtd>
</mtr>
<mtr>
<mtd class="eqnarray-1"></mtd>
<mtd class="eqnarray-2"></mtd>
<mtd class="eqnarray-3">
<mrow> <!-- dummy element added manually-->
<mrow>
<mspace width="1em" class="quad" />
<mo class="MathClass-bin">-</mo>
<mi>B</mi>
</mrow>
<mo class="MathClass-close">)</mo>
</mrow> <!-- this has no opening element-->
</mtd>
<mtd class="eqnarray-4">
<mtext class="eqnarray"></mtext>
</mtd>
</mtr>
</mtable>

As you will understand from the above, the problem is not with tex4ht,
but perfect MathML cannot be generated from given input.

If MathML is needed from your TeX math, definitely these rules shall
be taken care of while writing. The problem of incompatibilities
between different markup languages was in fact a theme in one of the
talks of TUG 2010 by Prof William Hammond which is available at
http://www.albany.edu/~hammond/presentations/Tug2010/profart.xhtml

Best regards
-- 
Radhakrishnan