Missing Latin superscript lowercase letters

[Kent Karlsson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230322/5064b0a4/attachment.htm>