RE: math alphabets, WAS: Proprietary Card Decks

From: Doug Ewell (
Date: Thu Apr 14 2011 - 13:40:14 CDT

  • Next message: Hans Aberg: "Re: math alphabets, WAS: Proprietary Card Decks"

    Hans Aberg <haberg dash 1 at telia dot com> 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.

    Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 | | @DougEwell ­

    This archive was generated by hypermail 2.1.5 : Thu Apr 14 2011 - 13:44:39 CDT