Re: mover vs latin chars with diacriticals

White Lynx and w3c MathML WG people,

The nightmare with MathML can be still poor that a "not finite" number of
ways to encode q-dot!

There are also additional variations in the mathml namespace, display
attributes, and others parts of the full code.

Take just the same TeX source  $\dot{q}$.

TtM 3.72 generates

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mover><mrow><mi>q</mi></mrow>
<mo>&middot;</mo></mover>
</mrow></math>


TexToMathML generates

<tex2mml xmlns="http://www.w3.org/1998/Math/MathML">
  <!-- This MathML has been generated by the TexToMathML application -->
  <!-- developed at the Ontario Research Center for Computer Algebra -->
  <!-- (ORCCA). Please report problems to TeXToMathML@orcca.on.ca -->
  <math overflow="scroll">
    <mover>
      <mi>q</mi>
      <mo>.</mo>
    </mover>
  </math>
</tex2mml>


IteX generates (including WS)

<math xmlns='http://www.w3.org/1998/Math/MathML'>

<mover><mrow><mi>q</mi>

</mrow><mo>&dot;</mo></mover>



</math>


ASCIIMath generates

  <math title="\dot{q}" xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mover>
        <mrow>
          <mi>q</mi>
        </mrow>
        <mo>.</mo>
      </mover>
    </mstyle>
  </math>
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mo></mo>
    </mstyle>
  </math>


But introducing own ASCII input ASCIIMath generates

  <math title="dotq" xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mover>
        <mi>q</mi>
        <mo>.</mo>
      </mover>
    </mstyle>
  </math>
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mo></mo>
    </mstyle>
  </math>


It appears obvious that a non standard as old TeX input \dot{q} is being
more "standard" and unified in practice than using the modern mathML w3c
recommendation.

For complementing the study next I submitted the above mathml outputs to
http://www.mathmlcentral.com/Tools/FromMathML.jsp

Choosing a 28 font-size on the Mathematica 5.2 advanced GIF settings I
retrieved all GIFS automatically generated.

ASCIIMath or ORCCA outputs directly generate error on Mathematica 5.2
online tool.

Of course, if you eliminate the tex2ml tag in ORCCA code then Mathematica
generates the GIF. But only anyone knowing MathML code is able to
recognize that tex2ml tag can be eliminated from the output. It would be
remember that w3c folks assume that MathML is a kind of postscript that
final authors would never see.

Since I know MathML output I am able to modify correct final code by hand,
for example I could eliminate redundant mrows generated by TtM. But, in
general, authors working with MathML do not know them are really encoding.
I reviewed some examples of very wrong code in the past.

Visual renderings of above codes are very different (as one would wait).
TtM originated GIF includes a small dot sited too above. ORCCA code
(corrected by hand as explained above) generates a big dot close to the q.

But again the most fascinating code is the obtained from the IteX approach
(see my review on Distler Musings blog). The GIF Mathematica generated
from IteX MathML output is a q and above a black filled rectangle of the
size of the wide of the own q approximately!!!

Would I remark that we are comparing here just a simple and trivial dot-q?

Could you imagine the diversity on outputs generated by different MathML
tools when more complex formulae is considered?

Any theoretical advantage of usage of a "standard" (technically mathML is
not standard just w3c recommendation not approved for standard) is lost in
the end. Moreover, as shown by

[http://www.mathmlcentral.com/Tools/FromMathML.jsp]

the visual rendering of some of above MathML codes in Mathematica is not
acceptable.

I would also remark that search engines will not work since "same" q-dot
could be served in different ways and I cannot imagine that kind of MathML
code is serving the author X using the tool Z. This problem may be
exponentially enlarged with realistic large formulae.

Moreover, none of above codes is semantically oriented (Unicode at least
is able to distinguish textual q-dot from mathematical q-dot (usually
interpreted as derivative).

Accessibility of above MathML codes is weak or inexistent when compared
with an old HTML + GIF + ALT model.

Unicode was also designed for off-line usage and let specific matching by
search engines and rendering quality will be better than via MathML.


Juan R.

Center for CANONICAL |SCIENCE)

Received on Monday, 1 May 2006 14:11:54 UTC