From: Hans Aberg (firstname.lastname@example.org)
Date: Thu Apr 14 2011 - 14:41:14 CDT
On 14 Apr 2011, at 20:40, Doug Ewell wrote:
>>> After Unicode has finished adding superscript versions of every
>>> imaginable math character, including all of the math alphanumerics,
>>> it would then have to add second-level, third-level, etc. versions of
>>> every character, so that one could enter "a to the b to the c to the
>>> (d times square root of 2)" in plain text. And don't forget
>>> subscripts of superscripts, and vice versa.
>> One way would be to enter a^b^c^(d·√2), only that '^' would be a
>> special superscript symbol. If the parser is intelligent enough, it
>> can infer that the parenthesizes are not needed in the rendering.
> Here you are positing a math-specific "parser" that accepts a plain-text
> expression in programming-language syntax, and displays an attractively
> styled, human-readable or compiled version of that expression. I assume
> such parsers are in common use, and I'm not talking about that. Maybe
> my use of "enter" was misleading.
> You had written, "Unicode does not have characters for say superscripts
> and subscripts, which are essential to math. My guess it would be too
> complicated to require it for current text-only renderers, but in the
> future that might change." You added examples of different types of
> application that care about either the appearance or the semantics of
> the expression.
> What I am trying to say is that encoding a comprehensive, or even
> minimally usable, set of superscript and subscript varieties of existing
> characters would not solve either the direct-layout problem or the
> semantic-layout problem, because of nesting and other aspects of math
> layout; and that, as Murray illustrated, an attempt to solve these
> problems more fully by encoding even more characters would become
> exponentially more complex and bulky.
You seem to assume that if one combines objects by means of subscripts and superscripts that results in a new character.
I think of it merely as additional rendering directions: just as there LTR and RTL, math uses a few more directions:
If one has a character, one can in math from it write in at least eight directions: the four corners, above, below, over, and after. In algebra, one may sometimes write function application f(x) as (x)f or x f which might possibly be viewed as RTL writing.
So one needs a way to indicate the writing directions from a character, and as you point out, groupings.
If one adds it in a computer language, it will parse it and render it using some GUI library. If one adds characters describing it to Unicode, then text editors would be required to have such capability, being more complex.
But what is the problem otherwise?
This archive was generated by hypermail 2.1.5 : Thu Apr 14 2011 - 14:44:24 CDT