- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 4 Oct 2016 15:52:21 -0400
- To: "Liam R. E. Quin" <liam@w3.org>, Bill Kasdorf <bkasdorf@apexcovantage.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Paul Topping <pault@dessci.com>
- Cc: Avneesh Singh <avneesh.sg@gmail.com>, Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>
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') || '') .split(/\s+/).map(parseFloat) ; 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 horizontally. 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 - http://berjon.com/ - @robinberjon • http://science.ai/ — intelligent science publishing •
Received on Tuesday, 4 October 2016 19:52:47 UTC