The LineServices post<https://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 tweaks<https://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 spec<https://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 Typeworks<http://www.tiro.com/> is handling this and it also did Cambria Math.
Murray From: Paul Topping [mailto:[email protected]] Sent: Friday, April 8, 2016 3:03 PM To: Murray Sargent <[email protected]>; Daniel Kinzler <[email protected]>; Moritz Schubotz <[email protected]>; [email protected]; Peter Krautzberger <[email protected]> Cc: Wikimedia developers <[email protected]>; wikidata-tech <[email protected]> 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:[email protected]] Sent: Friday, April 8, 2016 2:34 PM To: Paul Topping <[email protected]<mailto:[email protected]>>; Daniel Kinzler <[email protected]<mailto:[email protected]>>; Moritz Schubotz <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Peter Krautzberger <[email protected]<mailto:[email protected]>> Cc: Wikimedia developers <[email protected]<mailto:[email protected]>>; wikidata-tech <[email protected]<mailto:[email protected]>> 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 program<https://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 LineServices<https://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 properties<https://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 format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://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 stack<https://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
_______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
