[liblouis-liblouisxml] Re: mtable with inferred mtd
- From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
- To: <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Mon, 17 Mar 2014 11:27:54 -0700
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> 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> 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
Other related posts:
