Re: Superscript and Subscript Characters in General Use / Re: French Superscript Abbreviations Fit Plain Text Requirements

Gladly this thread comes now to a far better and very useful result.
A set of Unicode super- and subscripts are proven to be already promoted by Microsoft
in a fully validated way. From this we can expand to promote the use of a set of
Latin superscript letters. Connectedly, Microsoftʼs position of unsupporting the
OpenType rendering properties of U+2044 FRACTION SLASH (at least in a Latin script
context in Edge) turns out to be a fairly user-frienly, practice-oriented option.
That helps, too, to get around of holding peopleʼs feet to the fire about U+2044.

On Wed, 28 Dec 2016 13:47:00 -0800, Asmus Freytag wrote:
[…]
>
> Mathematical notation is a good example of such a mixed case: while
> ordinary variables can be expressed in plain text with the help of
> mathematical alphabets, the proper display of formulas requires markup.
> Even Murray Sargent's plain text math is markup, albeit a very clever one
> that re-uses conventions used for the inline presentation of mathematical
> expression. (Where that is insufficient, it introduces additional
> conventions, clearly extraneous to the content, and hence markup).
>
http://www.unicode.org/mail-arch/unicode-ml/y2016-m12/0119.html

Murray Sargentʼs Nearly Plain-Text Encoding of Mathematics (UnicodeMath) is in my
opinion a key gateway to the understanding of Unicode, and thus becomes a key point
in my communication about Unicode-supporting keyboard layouts. See version 3.1:
http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.pdf

Thanks to Asmus Freytag for drawing our attention to it!

What makes this notation so important to this threadʼs issue, is in that it uses
Unicode superscripts and subscripts as a valid and parseable alternative to the
[La]TeX-style notation that uses markup ('^' and '_'), “since Unicode has a full set
of decimal subscripts and superscripts. As a practical matter, numeric subscripts
are typically entered using an underscore and the number followed by a space or
an operator” (p. 7).

These Unicode superscript and subscript characters are parseable and are converted
to formatted digits at build. Hence they are unambiguous, not random characters as
sometimes alleged. They “should be rendered the same way that scripts of the
corresponding script nesting level would be rendered.” (p. 18)

Although fractions are ordinarily written with ASCII digits and slash, U+2044 can
be used to get skewed fractions (p. 5) built up in Microsoft Word (where fractions
can also be formatted using the math features). Combining both schemes, the user
may feel free to write fractions using super/sub scripts around U+2044, as suggested
in the already cited wiki proposing to add a huge autocorrect list for quick input:
https://answers.microsoft.com/en-us/msoffice/wiki/msoffice_word-mso_other/styled-fractions-in-windows/4a07d5fa-2484-4e39-b1f3-70bb3eb0c332

This is practice-oriented and user-friendly because relying only on the OpenType font
feature specified for U+2044 would dramatically restrict the number of usable fonts,
that in Latin script is traditionally several thousands, as opposed to complex scripts
for which HarfBuzz is primarily intended, where the number of available typefaces is
much smaller, so that full conversion to OpenType is feasible. So I think that the
correct rendering of U+2044 in HarfBuzz targets mainly these complex scripts. In
other scripts like Latin, the feature would then be a nice fall-off, that potentially
raises user expectations about professional (typographical) ligature rendering.

At the other end, for drafts and even “for simple documentation purposes”,
“plain-text linearly formatted mathematical expressions can be used ‘as is’” (p.29).
That can be extended to vulgar fractions in current text, and abbreviations.

This helps to understand that any font with inconsistent glyphs for Unicode subscript
and superscript digits is not Unicode conformant.
The same applies to superscript i and n (as mentioned in:
http://www.unicode.org/mail-arch/unicode-ml/y2017-m01/0093.html
). These inconsistent fonts don’t conform to the Unicode Standard specifying that
there is no functional difference between those characters that have the word
SUPERSCRIPT in their name, and those that donʼt:

TUS 9.0, §7.8, p. 327:
| The superscript forms of the i and n letters can be found in the
| Superscripts and Subscripts block (U+2070..U+209F). The fact that the latter
| two letters contain the word “superscript” in their names instead of “modifier
| letter” is an historical artifact of original sources for the characters, and
| is not intended to convey a functional distinction in the use of these
| characters in the Unicode Standard.
http://www.unicode.org/versions/Unicode9.0.0/ch07.pdf#G24762

Moreover, the Code Charts contain comment lines to these two characters, connecting
them to the set of Unicode superscript Latin letters named “MODIFIER LETTER”:

2071 SUPERSCRIPT LATIN SMALL LETTER I
* functions as a modifier letter
# <super> 0069
[…]
207F SUPERSCRIPT LATIN SMALL LETTER N
* functions as a modifier letter
# <super> 006E

Accordingly, the user can count on a whole small alphabet — except q, that has been
rejected arguing invented imaginary allegations on behalf of the UTC — displaying in
a consistent way in all complete, conformant fonts, with a running-text like layout
so far as the fonts have proportional advance width. To run a test, see example in:
http://www.unicode.org/mail-arch/unicode-ml/y2017-m01/0093.html (again).

Trying to conclude so far (please feel free to correct), I now believe and will
spread the word that following Microsoft — a user-friendly corporation eager to help
everybody make the most of Unicode — the users of any word processor and text editor
are welcome to use the Unicode repertoire as they need and like, while on the other
hand, the recommendations in TUS may be considered a mere official discourse for
encoding process management purposes, but with little through no real impact on
actual practice. Hence, National Bodies and user communities as well as developers
may issue usage recommendations of their own, to meet user expectations and propose
working methods additionally—or alternatively—to those provided by the Standard.

Regards,
Marcel
Received on Mon Jan 23 2017 - 03:30:55 CST