MathML should be allowed as first class markup in OPS
| Project: | EPUB Maintenance |
| Component: | Open Publication Structure (OPS) |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | future consideration |
Jump to:
Currently, math must be marked up as either an image or SVG. However, doing so means that the math is neither accessible, searchable, or computable (ie, it can't be copied and used in computation software such as Mathematica or Maple). MathML was designed as an XML compatible solution to those problems.
MathML can be used in a DAISY book [1], but not in OPS because (at least by my reading), OPS is locked to a specific version of the DTBook DTD and can not be extended. Note that support for MathML in DAISY readers is relatively easy because DAISY MathML support requires use of MathML's alttext and altimg attributes, so display or audio are easily extracted from the MathML if native support for MathML is not present.
On the XHTML side, MathML can be embedded inside of a switch statement as an XML island. [2] provides a suggestion for how that might be done. Embedding MathML in a switch results in a bloated document and the need to maintain parallel information. It also requires the authoring tools to generate MathML, images, and SVG, along with the ability to download fonts.
Note: using CSS, limited support for rendering MathML can be achieved [3], but full support requires a MathML renderer or internal converter to (for example) SVG.
[1] http://www.daisy.org/projects/mathml/mathml-in-daisy-spec.html
[2] http://www.dessci.com/en/reference/ebooks/EPUBMath_spec.htm
[3] http://www.w3.org/TR/mathml-for-css/
It should be moved to "future directions" and closed.
- Login to post comments
Comments
#1
This is inaccurate, at least on one level -- MathML can be supported in OPS, via an inline XML island. To wit, MathML is such a specialized language that including it in our core seems to place an onerous burden on tool developers. If someone needs to display MathML, they should use an inline island, and then the tool developers can choose whether or not they support it.
#2
My statement was that MathML can not be supported in OPS using the DTBook vocabulary because the DTD cannot be changed, despite DAISY having approved the MathML extension (and its extension to the DTD). If you don't care about validation, cross linking with the SMIL part of the DTBooks, etc., then XML islands can be used, but you've thrown out some of the things that make a DAISY book the gold standard for accessibility.
My suggestion is that, as was done for DAISY, the 'altimg' and 'alttext' attributes of MathML be required and not be optional. That allows easy support for tool developers who don't want to support MathML (either natively or through CSS), and still avoids the bloat of having a switch with up to three cases (which is hard on authoring systems). It minimizes the burden on publishers, many of whom already use MathML internally in their workflow.
I do agree that supporting math requires effort if you don't want to use an image. However, not supporting math is cutting out one of the three "R"s in school. As I've said to others many times, every child takes a math every school day. If the math is not accessible, which is the case with the OPS standard as it now stands, those students with visual and learning disabilities do not have equal access to ebooks for the math and science courses they take every day.
#3
I agree that supporting MathML and the current DTBook standard should be a top-drawer item for the next version of EPUB. However, to change it now may introduce significant validation and tool support issues with current products. We have the balance the needs of our community with doing the right thing.
And trust me when I say you're unlikely to find a bigger proponent than I for accessibility.
#4
Given that there has been no change or other comments on this topic in several days, I am proposing the following resolution:
It should be moved to "future directions" and closed.
#5