Rather than discussing whether MathML is a failed standard, web or otherwise, I recommend we discuss specific, constructive topics. I suggest the discussion be in the context of MathML where appropriate, not because I want to defend MathML but because it is an existing standard. It is a place to start. If the solutions we reach replace MathML all or in part, so be it. Let's not start by throwing it out but by addressing its problems. We can certainly create a new standard if MathML can't be fixed. Finally, if this is the wrong venue for this topic or any other, please suggest a better one. If there are other parties that need to know about the discussion, please let them know.
Assuming others agree, let’s start with perhaps an important issue. Should Presentation MathML dictate a specific rendering or leave formatting choices up to the renderer. Peter says, "I have the impression people generally expect consistent rendering across browsers. But anecdotal evidence is, well, anecdotal." I would agree with this statement. People do expect this. I believe they get that expectation from TeX but it does make sense. Why would a user want a different rendering in a different browser?
The reason I said "no" to this before was because the MathML spec leaves a lot of rendering decisions up to the implementation. Someone reading the MathML spec should NOT expect all renderings to be the same. In fact, the spec doesn't specify the rendering at the required level of detail. Doing so would be difficult. TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself.
We could create a MathML 4 in which the graphical rendering is specified in writing and in detail. Implementations would be constrained much more than by the current spec. Another way to achieve this goal is to create a reference implementation. This would be the TeX way, or close to it.
We could even map MathML onto TeX somehow and then defer to TeX's rendering. The MathML spec would be annotated by TeX templates (perhaps macros) that serve to define the rendering. The reference implementation would consist of a MathML-to-TeX convertor and the TeX engine itself. Implementations that intend to abide by the MathML 4 spec could use the reference implementation or roll their own.
When I say rendering above, I only mean graphical rendering. When we talk about audio or braille rendering, things are much less clear. The state of the art in MathML-to-speech has certainly not reached a point where everyone can agree. Besides, there is personal taste of the reader and multiple languages to consider.
Ok, I'll stop there and take a breath.
Paul
I agree that it's worthwhile to take a step back and consider the bigger picture, but wouldn't a more appropriate discussion for a Wikidata list be -- is there a critical need to represent mathematical notations in Wikidata and, if so, what form should that take?
On Thu, Apr 7, 2016 at 7:25 PM, Paul Topping pault@dessci.com wrote:
Rather than discussing whether MathML is a failed standard, web or otherwise, I recommend we discuss specific, constructive topics. I suggest the discussion be in the context of MathML where appropriate, not because I want to defend MathML but because it is an existing standard. It is a place to start. If the solutions we reach replace MathML all or in part, so be it. Let's not start by throwing it out but by addressing its problems. We can certainly create a new standard if MathML can't be fixed. Finally, if this is the wrong venue for this topic or any other, please suggest a better one. If there are other parties that need to know about the discussion, please let them know.
Assuming others agree, let’s start with perhaps an important issue. Should Presentation MathML dictate a specific rendering or leave formatting choices up to the renderer. Peter says, "I have the impression people generally expect consistent rendering across browsers. But anecdotal evidence is, well, anecdotal." I would agree with this statement. People do expect this. I believe they get that expectation from TeX but it does make sense. Why would a user want a different rendering in a different browser?
The reason I said "no" to this before was because the MathML spec leaves a lot of rendering decisions up to the implementation. Someone reading the MathML spec should NOT expect all renderings to be the same. In fact, the spec doesn't specify the rendering at the required level of detail. Doing so would be difficult. TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself.
We could create a MathML 4 in which the graphical rendering is specified in writing and in detail. Implementations would be constrained much more than by the current spec. Another way to achieve this goal is to create a reference implementation. This would be the TeX way, or close to it.
We could even map MathML onto TeX somehow and then defer to TeX's rendering. The MathML spec would be annotated by TeX templates (perhaps macros) that serve to define the rendering. The reference implementation would consist of a MathML-to-TeX convertor and the TeX engine itself. Implementations that intend to abide by the MathML 4 spec could use the reference implementation or roll their own.
When I say rendering above, I only mean graphical rendering. When we talk about audio or braille rendering, things are much less clear. The state of the art in MathML-to-speech has certainly not reached a point where everyone can agree. Besides, there is personal taste of the reader and multiple languages to consider.
Ok, I'll stop there and take a breath.
Paul _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."
Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout programhttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/ uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.
It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServiceshttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/. And it should be way faster than Java script code.
My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math propertieshttps://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear formathttp://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf to the OMMLhttps://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stackhttps://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx originally developed for the linear format.
The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.
Murray
Murray,
I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text?
I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations.
Paul
From: Murray Sargent [mailto:murrays@exchange.microsoft.com] Sent: Friday, April 8, 2016 2:34 PM To: Paul Topping pault@dessci.com; Daniel Kinzler daniel@brightbyte.de; Moritz Schubotz schubotz@tu-berlin.de; www-math@w3.org; Peter Krautzberger peter.krautzberger@mathjax.org Cc: Wikimedia developers wikitech-l@lists.wikimedia.org; wikidata-tech wikidata-tech@lists.wikimedia.org Subject: RE: should MathML dictate a specific graphical rendering
Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."
Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout programhttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/ uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.
It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServiceshttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/. And it should be way faster than Java script code.
My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math propertieshttps://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear formathttp://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf to the OMMLhttps://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stackhttps://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx originally developed for the linear format.
The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.
Murray
The LineServices posthttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/ includes a description of an incredible afternoon several of us spent with Donald Knuth back in 2004. Among many things, he demonstrated how he tweakshttps://blogs.msdn.microsoft.com/murrays/2011/04/30/two-math-typography-niceties/ his TeX documents. We did automate some of these tweaks, notably creating “cut-ins” for subscript/superscript positioning. These cut-ins are part of the OpenType math spechttps://blogs.msdn.microsoft.com/murrays/2014/04/27/opentype-math-tables/. Knuth explained that he didn’t want to go back and change TeX due to its archival usage. Naturally non-math concepts such as revision tracking and embedded objects along with international text had to be accommodated in our implementation. This was another reason for using OMML instead of MathML as the preferred math XML; you can embed other XMLs into OMML. In principle you can do that using the MathML <semantics> element, but it’d be somewhat cumbersome. The Office layout is essentially the same as TeX’s. It’ll be interesting to see how the two compare when the STIX font is finally released with full OpenType math table support. Tyro Typeworkshttp://www.tiro.com/ is handling this and it also did Cambria Math.
Murray
From: Paul Topping [mailto:pault@dessci.com] Sent: Friday, April 8, 2016 3:03 PM To: Murray Sargent murrays@exchange.microsoft.com; Daniel Kinzler daniel@brightbyte.de; Moritz Schubotz schubotz@tu-berlin.de; www-math@w3.org; Peter Krautzberger peter.krautzberger@mathjax.org Cc: Wikimedia developers wikitech-l@lists.wikimedia.org; wikidata-tech wikidata-tech@lists.wikimedia.org Subject: RE: should MathML dictate a specific graphical rendering
Murray,
I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text?
I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations.
Paul
From: Murray Sargent [mailto:murrays@exchange.microsoft.com] Sent: Friday, April 8, 2016 2:34 PM To: Paul Topping <pault@dessci.commailto:pault@dessci.com>; Daniel Kinzler <daniel@brightbyte.demailto:daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu-berlin.demailto:schubotz@tu-berlin.de>; www-math@w3.orgmailto:www-math@w3.org; Peter Krautzberger <peter.krautzberger@mathjax.orgmailto:peter.krautzberger@mathjax.org> Cc: Wikimedia developers <wikitech-l@lists.wikimedia.orgmailto:wikitech-l@lists.wikimedia.org>; wikidata-tech <wikidata-tech@lists.wikimedia.orgmailto:wikidata-tech@lists.wikimedia.org> Subject: RE: should MathML dictate a specific graphical rendering
Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."
Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout programhttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/ uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.
It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServiceshttps://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/. And it should be way faster than Java script code.
My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math propertieshttps://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear formathttp://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf to the OMMLhttps://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stackhttps://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx originally developed for the linear format.
The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.
Murray
Murray Sargent writes in part:
It's good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven't given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it'll likely look like TeX, since both IE and Edge use LineServices. And it should be way faster than Java script code.
This would be good to see.
-- Bill
On 04/09/2016 02:42 PM, William F Hammond wrote:
Murray Sargent writes in part:
It's good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven't given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it'll likely look like TeX, since both IE and Edge use LineServices. And it should be way faster than Java script code.
This would be good to see.
Oh, this would more than "good", it would be... Well, let's go with the ever popular Sports Analogies:
It would be a game changer. Moreover, knowing Murray, I have no doubt that it'd reset the bar for math rendering on the web.
Sigh. It's all the more frustrating in that MS has already done the hard part (not to trivialize the integration & testing).
bruce
wikidata-tech@lists.wikimedia.org