Epub-specs: Reading system conformance for MathML should be loosened and clarified to be more realistic

[BCWalters]

Reading systems based on HTML layout engines provide various levels of support for MathML:

1. Reading systems based on Mozilla or WebKit support MathML natively
2. Other reading systems can use MathJAX in some form--online only, download it locally on demand, ship it with the app, etc.
3. Other reading systems display the fallback image and alternate text when available
4. Others don't display fallback images (because HTML layout engines don't do it by default)

The content documents spec requires that MathML is supported by reading systems by reading systems:
It MUST support processing of Presentation MathML using semantics defined by [MATHML].

but then explains that this is not the reality in the following section:

Fallback Content
As Reading System support for MathML rendering is inconsistent, Authors are encouraged to provide a fallback image using the altimg attribute on the math element. It is RECOMMENDED that the dimension and alignment attributes (altimg-width, altimg-height and altimg-valign) be used in conjunction with the altimg attribute.

The spec should more clearly acknowledge the state of the world by requiring that reading systems either fully support MathML OR support rendering.

[deborahgu]

I'm confused by "requiring that reading systems either fully support MathML OR support rendering". What's the difference between supporting rendering and supporting MathML? Do you mean, support mathml natively or support integration with an alternate mode of rendering such as mathjax?

[GarthConboy]

Maybe we just we just acknowledge that this topic is no more broken in 3.2 than in previous versions, and just leave it alone.

[BillKasdorf]

If we leave it alone in the spec (and I see the wisdom of that) then we should really work on a viable Best Practices recommendation that enables (a) publishers to feel safe in putting MathML in EPUBs even if _only for AT_ (e.g., they don't trust the RSs to render it properly) and (b) AT to prioritize the MathML. I believe this what George, Charles, et al. have been working on; the new Math test book for epubtest.org should be a way to test and develop a best practices recommendation.

[clapierre]

I agree, we come up with best practices for publishers on how they can put mathML into their EPUBs that will always render the way the want with an image and we expose the MathML to AT if the reading system supports it with the fallback of the math equation in alt text when mathML is not supported by the reading system.

For those reading systems that don't do a good job of exposing the MathML to AT well the consumers will figure out which reading system does a better job and will use those systems and that will force the reading systems to do a better job of supporting MathML.

We have to start somewhere and waiting for MathML to be supported correctly by all reading systems will never happen.

[deborahgu]

I understand the desire to remove fallback methods, because the way to make mathml happen is to require mathml. However. If we talk about removing fallbacks, we need to recognize that providing accessible rendering of presentation MathML is non-trivial. It's not that the normative requirement "providing MathML to the accessibility tree" isn't necessarily sufficient for accessibility, but it's also not as trivial as saying it _is_.

Perhaps we should ask for a recommendation from the Math CG's a11y task force, with the understanding that we want to balance the two competing strong desires:

1. Require MathML support
2. Require an accessible rendering that can be supported by AT (I assume we are permitting, say, MathJax + MathPlayer to count as AT).

[avneeshsingh]

I would like to remind two points.

• One key principle for EPUB 3.2 revision is that it should not bring a drastic change. The main objective of spec revision is to make it more backward compatible.
• We should also avoid over specifying because MathML visual renderning and MathML accessibility is changing. If we over specify then it may happen that it becomes less relevant after some months.

[JCBlair]

Unfortunately, until MathML is more widely supported, a fallback method of presenting an image is required in order for a publisher to, as Bill suggests “feel safe.” I’m in agreement with having best practices and exposing the MathML to AT, but I imagine the compliance on this will be far and wide, as well. There’s really nothing wrong with the spec, as is, stating that a “conformant” reading system must support processing and visual rendering of MathML. A reading system can choose to be non-conformant.

[dauwhe]

I'm a bit concerned about our advice for fallbacks in the spec. Is this advice actually helpful? Are there reading systems that don't process most of MathML, but do process altimg, etc.?

I wonder if we should drop the entire "fallback content" section (2.5.1.4), and just have a note:

NOTE: Reading System support for MathML rendering is inconsistent. There are many ways to include equations in EPUB, and which solution is best depends on both the content and the context.

[avneeshsingh]

There are many more ways to provide fallback, we have created MathML test book to test these. It is at 1.
At the same time, I also believe that the statement should not undermine use of MathML. It should say that reading systems support for rendering MathML is work in progress and is inconsistent at this point of time. Therefore reading systems should support appropriate fallback mechanisms.

1.
http://epubtest.org/epubs/epub30-test-0330-20180905.epub

[teytag]

Hi Avneesh,

I looked at the MathML test book on the IOS platform. Quite successful. I would like to thank those who made the test book.

Best regards

N. Erhan Uzumcu
Art Director and EPUB Designer

On Sep 7, 2018, at 7:04 AM, Avneesh Singh [e-mail] wrote:

There are many more ways to provide fallback, we have created MathML test book to test these.

[dauwhe]

How about:

NOTE: Reading System support for MathML rendering is inconsistent. Authors may use many different ways to include equations in EPUB, and which solution is best for them depends on both the content and the context. Reading Systems SHOULD support common fallback mechanisms.

[GarthConboy]

I like the above as I believe there are RS's that do opt for the fallbacks (he says without firm data to back the contention).

[mattgarrish]

It sort of sounds like we're undercutting the need for MathML in the MathML section, though. It's still the most accessible means of providing math, even if support remains imperfect.

Trying to remember back to 3.1, wasn't the reason we kept mention of altimg because we were dropping epub:switch and were providing that as guidance for how to provide an alternative image? It wasn't there for accessibility or anything so noble.

How about instead of dropping the section entirely, we change the title to "Fallback Images" and reword it to remove the part about inconsistent support:

It Authors provide a fallback image for MathML using the altimg attribute, it is RECOMMENDED that the dimension and alignment attributes (altimg-width, altimg-height and altimg-valign) be used in conjunction with it.

Fallback images MUST conform to the constraints for Publication Resources defined in EPUB Publication Conformance [EPUB32].

It seems like the least we need to say on the topic.

[GarthConboy]

I like the accuracy of Dave's better. But, can live with either.

[mattgarrish]

But what are "common" fallbacks methods, and how "should" they be supported? If we're going to use normative language, we can't dodge that problem. As noted in the original post above, the altimg and alttext might be used, but there's no consistency. You're just as likely to find a scrambled string of text content.

But if we're going to start writing notes like this, why stop here? FXL is probably about as inconsistently supported, so should we add notes to every property? SSML, PLS? Where do we stop?

I'm also not sure we're going in the right direction of answering this issue. Isn't it only asking that we be clearer that third-party rendering is acceptable? (i.e., it doesn't have to be native rendering)

[dauwhe]

Do we know of any reading systems that don't support MathML, but do support altimg?

I'm also not sure we're going in the right direction of answering this issue. Isn't it only asking that we be clearer that third-party rendering is acceptable? (i.e., it doesn't have to be native rendering)

Yes!

EPUB says,

It MUST support processing of Presentation MathML using semantics defined by [MATHML].

I find that statement a bit hard to, well, process. It appears that a script that turned MathML markup into its JSON equivalent would be compliant. Even reading the MathML spec itself isn't as helpful as one would hope:

We define a "MathML processor" to mean any application that can accept, produce, or "roundtrip" a well-formed MathML expression. An example of an application that might round-trip a MathML expression might be an editor that writes a new file even though no modifications are made.

MathML defines three types of compliance: Input, output, and round-trip. I think only the first is of interest to us:

1. A MathML-input-compliant processor must accept all well-formed MathML expressions.

For example a MathML-input-compliant validating parser which implements the MathML specification returns a truth value. A MathML-input-compliant renderer faithfully translates a MathML expression into application-specific form allowing native application operations to be performed.

So I think what we're looking for is a Presentation MathML-input-compliant renderer (understanding that rendering is not just visual rendering).

So I would propose some new spec text below, and also just eliminate the section on fallback images, unless we have evidence that this particular type of fallback is actually helpful in existing reading systems.

2.5.1.3 Reading System Conformance

A conformant EPUB Reading System MUST meet all of the following criteria for supporting MathML embedded in XHTML Content Documents:

1. It MUST be an input-compliant renderer for Presentation MathML, as defined in the MathML specification.

2. It MAY support rendering of Content MathML found in xml-annotation elements.

3. If it has a Viewport, it MUST support visual rendering of Presentation MathML.

Note: EPUB Reading Systems may choose to use third-party libraries such as MathJax to provide MathML rendering.

[mattgarrish]

Yes, this is getting us to a much better place! I'd rather focus on what we expect than all the other issues around support and fallbacks. We know that reality, and we already agreed in 3.1 that the accessibility techniques were a better place to deal with those shifting sands.

[dauwhe]

Closed via #1134