I vote to support MathML 2 but we need to have a fallback in case of
errors such as missing mtr or mtd elements. And in case of differing
numbers of mtd elements and no column span attributes. A filter that
just adds the missing pieces at the end of a row would be sufficient.
]
John G
*From:*liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] *On Behalf Of *Neil
Soiffer
*Sent:* Monday, March 17, 2014 11:08 AM
*To:* liblouis-liblouisxml@xxxxxxxxxxxxx
*Subject:* [liblouis-liblouisxml] Re: mtable with inferred mtd
By mistake, I ended up quoting the MathML 2 spec, the MathML3 spec is
more terse on this: "A matrix or table is specified using the
|mtable| element. Inside of the |mtable| element, only |mtr| or
|mlabeledtr| elements may appear. (In MathML 1.x, the |mtable| was
allowed to ‘infer’ |mtr| elements around its arguments, and the |mtr|
element could infer |mtd| elements. This behaviour is deprecated
<http://www.w3.org/TR/MathML/chapter2.html#interf.deprec>.)
The deprecated link above explains what "deprecated" means.
Specifically, if you want to claim you support MathML 1, you should
support the inferred mtds. But you should also support the other
deprecated features of MathML 1 (which are likely listed somewhere,
but I don't know where).
The example you give is invalid MathML 2 and invalid MathML 3. It
would only be valid MathML 1.
Neil
On Mon, Mar 17, 2014 at 10:54 AM, Michael Whapples <mwhapples@xxxxxxx
<mailto:mwhapples@xxxxxxx>> wrote:
Hello Neil,
So are you saying that something like:
<mtable>
<mtr>
<mtd>x</mtd>
<mtd>y</mtd>
</mtr>
<mtr>
<mtd>s</mtd>
</mtr>
<mtr>
<mtd>g</mtd>
<mtd>h</mtd>
</mtr>
</mtable>
is invalid in MathML 2.0?
I did not check the MathML version of the specification google came up
with, so may be that is wrong.
I am not sure which version of MathML the document causing the issue
is using.
Michael Whapples
On 17/03/2014 17:44, Neil Soiffer wrote:
Note that the spec says:
"In MathML 1.x, the |mtable| element could infer |mtr| elements
around its arguments, and the |mtr| element could infer |mtd|
elements. In other words, if some argument to an |mtable| was not
an |mtr| element, a MathML application was to assume a row with a
single column (i.e. the argument was effectively wrapped with an
inferred |mtr|). Similarly, if some argument to a (possibly
inferred) |mtr| element was not an |mtd| element, that argument
was to be treated as a table entry by wrapping it with an inferred
|mtd| element. MathML 2.0 deprecates
<http://www.w3.org/TR/MathML2/chapter7.html#interf.deprec> the
inference of |mtr| and |mtd| elements; |mtr| and |mtd| elements
must be used inside of |mtable| and |mtr| respectively. "
MathML 2 came out over 10 years ago, so hopefully no one is still
generating them. Deprecation means that readers should still
accept them but writers should not generate them.
If you have an uneven number of mtd elements, it is hopefully
because of the rowspan and columnspan attrs. These do occur with
some regularity, so I strongly recommend supporting them.
Neil
On Mon, Mar 17, 2014 at 10:26 AM, Michael Whapples
<mwhapples@xxxxxxx <mailto:mwhapples@xxxxxxx>> wrote:
Hello,
There was a bug where liblouisutdml was inserting additional text
other than the actual translation into a brl node.
Brandon noticed a particular mtr element which was causing this.
It turns out that the problem with that mtr element was that it
only contained one mtd element where as others had two mtd elements.
According to the MathML specification this is perfectly legal and
what the software should do is infer empty mtd elements to the
right of the explicitly given mtd element on that row, so that the
explicit and inferred mtd elements equals the number of columns in
the table.
It appears LibLouisUTDML is not obeying this part of the
specification.
My main question is how we want to go about solving this, should
it be fixed in LibLouisUTDML or should applications correct this
in the XML they give to LibLouisUTDML?
I would say that it would be more correct that LibLouisUTDML deals
with this. However it probably is simpler todeal with in other
applications with higher level languages like Java.
Also there is a second question relating to this, how should
LibLouisUTDML deal with mtd elements with rowspan and columnspan
attributes which are greater than 1? Is there currently any
feature of LibLouisUTDML which can deal with rowspan or columnspan?
It probably is worth trying to fix rowspan and columnspan at the
same time as fixing inferring mtd elements, unless its deemed that
rowspan and columnspan are lower priority.
Michael Whapples
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
