Re: [mediaqueries] MathML

On 04/10/2016 15:31 , Liam R. E. Quin wrote:
> On Tue, 2016-10-04 at 18:47 +0000, Bill Kasdorf wrote:
>> [...] people are viewing MathML, and the potential for using MQs in
>> EPUBs, simply as a display/rendering issue.
> I think that this is a majority view for Web and HTML people - even
> though it's not a view shared e.g. by most XML people, who tend to be
> interested in reuse. EPUB straddles the boundary here.

Speaking as a Web/HTML person (if admittedly a heavily bastardised one)
I think there's definitely interest in reuse across the board. Reuse is
what makes accessibility possible, it's also what makes
machine-readability work — which is important for long-term archival
amongst other things. I think some people are only interested in the
rendering because they've had to give up on the rest, not because it
really is what they prefer.

> It might be the case that a standardized, reversible MathML <-> SVG
> mapping could go a long way, although there are a number of limitations
> with the SVG approaches I've seen so far, including breaking equations
> over long lines, aligning the dominant equation baseline correctly,
> vertical alignment of = signs of a series of equations, correct
> placement of equation numbers at or in the margin. But there are
> limitations with MathML in practice too (such as it not working at all
> in a browser or reader). And there are other use cases for breaking SVG
> diagrams across lines (e.g. Manga, or making accessible infographics)
> and for margin alignment, so maybe there's more promise in what Robin
> called I think the pretty squiggles than it might seem at first.

I would definitely be very happy to see a way of making SVG or HTML be
annotated in such a way that it has pretty squiggles that are also
semantic. That would be an ideal option. It is far from trivial though.
Part of the problem is that mathematical notation has massively
overloaded semantics, but asking authors to create maths content
semantically is nigh impossible.

We could aim a bit lower and fix the issues you mention with aligning
multiple SVGs (so that breaking up a long equation can happen just with
a list of inline boxes).

We use something like the following to get the baseline (I'm glossing
over some details):

  let h = parseFloat(svg.getAttribute('height'))
    , vb = (svg.getAttribute('viewBox') || '')
  if (h || vb.length) {
    let va = -(vb[3] + vb[1]) / (vb[3] / h);
    svg.setAttribute('style', `vertical-align: ${va}ex;`);

I suspect that is quite specific to the output that MathJax produces though.

I wonder if CSS has given thought to alignment anchors between boxes
that could be used to automatically lay things out vertically and

Dave Cramer has a nice hack using flexbox and generated content to do
equation numbering. In fairness the feedback we've had from customers
has more been about the fact that the counters they want aren't always
completely sensible so we'd have to be able to start a counter with a
value from a data-* attribute for instance.

• Robin Berjon - - @robinberjon
• — intelligent science publishing

Received on Tuesday, 4 October 2016 19:52:47 UTC