Peter Constable wrote: > Doug Ewell responded: > > > an image of mathematical or engineering equations wouldn’t > > exactly be the best supporting evidence for encoding them in plain text. > > Not only would it not be the best supporting evidence, it wouldn’t be > considered supporting evidence _at all_ since math formula layout is not > plain text. Says who? There is no law of nature (or of omputing) that says that math expressions must be non-plain text. Just because all of neqn/eqn, (La)TeX, MathML, OMML, and indeed UnicodeMath are representations of math expressions that are *not* plain text does not mean that math expressions must be expressed by a higher level protocol. I.e. it could very well be a text level protocol (where the ”math controls” are not expressed as printable text, but as control codes). Further, if some symbol/letter for some reason only ever occurred in superscript position in math expressions, such examples would still be supporting evidence for that symbol/letter. The closest practical example I can think of is the degree sign, which in origin is a superscript 0.
Asmus Freytag wrote: > I[n] mathematical typesetting what is superscripted is not the individual > letter, but the expression. In principle, the superscripted expression > is arbitrarily complex and thus the superscript is fully recursive. > > This is precisely the kind of situation where hardcoding anything is not > helpful. I would go even further than that, and say that with very few exceptions, characters that have a compatibility decomposition have no business in a math expression. In my little project "math anywhere" (ok, I just thought of that name, and no, of course I cannot implement it everywhere) I'm proposing a plain text format for math expressions. Plus a version that is compatible with HTML and SVG. And also a version that one can be best described as a "mark-down" version that is (relatively) easy to input via a keyboard; all equivalent in what can be expressed. See https://github.com/kent-karlsson/control/blob/main/math-layout-controls-2023-A.pdf <https://github.com/kent-karlsson/control/blob/main/math-layout-controls-2023-A.pdf>. The plain text format for math expressions can well represent math expressions in an otherwise plain text context. Whether you want to see the math expression themselves as plain text is very much in the eye of the beholder. The HTML/SVG compatible version does not have "clay feet”. The price for that is that additional parsing is needed. Unusual in that that parsing must work on the DOM, but otherwise nothing strange and basically the same parsing as for the ”plain text” version (where the parsing of course works on the text). This (or these, considering the three variants) is also the only format for math expression representation that can handle RTL math expressions reasonably. /Kent K
