Missing Latin superscript lowercase letters

[Kent Karlsson]

> 24 mars 2023 kl. 14:23 skrev Gabriel Tellez via Unicode <unicode at corp.unicode.org>:
> 
> Mathematical typesetting and proper musical notation are not in the scope of Unicode.

Math expressions are sufficiently in scope for Unicode to be dealt with in several documents published 
on the Unicode site (not only proposal documents, other more ”permanent” documents as well).

> On Thu, Mar 23, 2023 at 11:43 AM Giacomo Catenazzi via Unicode <unicode at corp.unicode.org <mailto:unicode at corp.unicode.org>> wrote:
> 
> In any case, to display true maths, we need a specialised engine (and 
> fonts). We are far from having current shaping engines (and fonts) to 
> display maths in a nice way. (and personally I prefer that developers of 
> shaping engines will works on improving the actual engine and fonts for 
> human languages, before to go on such specialised field (which we have 
> already good tools).

Just about EVERY school child (ok, only a few of them will become mathematicians, more of them will
become engineers, but that is beside my point) world-wide will study some math. Requiring them to
learn LaTeX or use some clumsy (!!, sorry) tool to write math expressions on computers, however, is
not a future I’d like to see. It should be light-weight, usable just about anywhere, for just about any
level of math (from children’s school classes up to university undergraduate level math and maybe
even beyond) and any math editing tool should be easy to use.
 
In my proposal for new representation formats (inter-equivalent) for math expressions I have seen to:
Handle combining characters correctly (they apply to a combining sequence preceding it 
(modulo canonical equivalence), NEVER to a math expression).
Allow for easy handling of multi-letter variables (identifiers) (among the other, existing, 
formats, it seems to only be (La)TeX that can handle that fairly well).
Handle bidi correctly and reliably, leaving the math expression AUTHOR in charge of 
which subexpression goes where, and which direction arrows and other math symbols 
go (the display system must not mess with that).
Handle math styles correctly, esp. when it comes to being able to handle multiletter 
variables but also in general (the “MATHEMATICAL” characters are esp. problematic and 
must be forbidden).
Have an XML representation that is 100% compatible with the non-XML representations, 
and still does not suffer from “tag bloat”.
Have several representations suitable for different representation contexts: XML, control 
codes (e.g. ECMA-48 formatting), “mark-down”.
Have the representation schemes be deeply integrateable with their representation context.
…

So, ok, that was a big plug for my math expression representation proposal. I don’t have a huge
organisation behind me, so I’m taking this opportunity to promote it… Read all about it in 
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>.
Sorry for it being all of 61 pages long (and the markdown is given on page 61…).
 
/Kent K

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230517/55ea9e5a/attachment.htm>