Re: Superscript asterisk---reference (correction)

From: Jonathan Coxhead (jonathan@doves.demon.co.uk)
Date: Fri Jul 02 1999 - 14:26:41 EDT


   The reference for the digamma function is really: Jeffreys and
Jeffreys, Methods of Mathematical Physics (3rd ed), Cambridge
University Press, 1978, p465. If encoded with the new mathematical
symbols, the formula would appear as

                     <d>
   <digamma>(<z>) = ------ <l><o><g> <z>!
                    <d><z>

(where <z> = "letterlike symbol italic z", <l> = "letterlike symbol
roman l", etc), and with the combining mark approach as

   <digamma>(z<italic>) = d<fraction><group>dz<italic><pdf> log
z<italic>!

The first would appear in a renderer that implemented only up to
Unicode 3.0 as

                     ?
      <digamma>(?) = -- ??? ?!
                     ??

the second as

      <digamma>(z) = d/dz log z!

   (The <digamma> remains in both because there is no proposed
"letterlike symbol digamma".)

 | As I wrote, we did consider combining marks as a means to
 | avoid combinatorics (but note that they are very different from the
 | stateful controls in your suggestion!) but felt that using that
 | mechanism to affect the style of a letter was inappropriate.

   I think there may be a small misunderstanding here: the PRESENTATION
SUGGESTIONS are no more stateful than any other existing combining
mark; START GROUP is no more stateful than, e g, LEFT-TO-RIGHT
OVERRIDE.

 | I'm currently working out a reference implementation for bidi that
 | will implement these characters in a way that is *precisely*
 | identical to the way you would get with markup. One of the things I
 | am learning is, that short of duplicating the action of a markup
 | parser, i.e. removing the controls and replacing them by style runs,
 | it is *almost* impossible to get the right behavior.

   Yes, I've had a go at this too. It was the experience gained while
doing it that let to my current ideas: I wanted to be able to render
as much as possible with a minimal glyph set but a sophisticated
renderer. The idea of the PRESENTATION SUGGESTIONS as productive
combining marks initially arose purely out of a desire to do something
more regular with those annoying little compatibility flags written in
the Unicode Standard as <black-letter>, <double-struck>, etc.

   The fact that you could do a surprisingly good job of maths and the
Finno-Ugric Phonetic Alphabet (which I hadn't heard of then) with just
13 new characters came as somewhat of a surprise, which is why I wanted
to share it.

 | If the bidi algorithm had been invented after the rise of HTML, it
 | might have well been the case that we would NOT have coded these
 | characters.

   I would dispute the necessity of history here: from my outsider's
perspective (and I follow Unicode, H T M L, X M L, Math M L, etc,
fairly closely), it seemed as though the "dir = rtl" and "dir = ltr"
attributes introduced into H T M L 4.0 were just a higher-level clone
of the features already in Unicode. In other words, if the characters
hadn't been in Unicode, I doubt they would have got into H T M L.

 | I won't argue elegance with you (or anyone here). My current
 | understanding of this issue has come to where I think that
 | mathematicians' use of letters and ordinary text use of letters are
 | distinct. In math, it makes no sense to have both a LATIN CAPTIAL A
 | and a GREEK CAPITAL ALPHA. With most fonts, readers can't tell them
 | apart, and unlike text there is no word-context for a variable.
 | Computer Modern fonts all explicitly unified these letters in all
 | styles.

   The trouble with this viewpoint is the fact that, once there are
italic, bold, etc, variants of the Latin alphabet in Unicode, people
are going to use them in written text for emphasis, or to be cute,
or whatever. There is no reason not to, after all, and no way to stop
them, and the results will look much nicer. Mathematicians may argue,
"But those are *our* characters!", but no-one will listen: the new
characters just will not be confined to only a mathematical usage. I
guarantee it!

   I suppose my perspective is that a character encoding belongs to its
user base, not the standards body that encodes it, in much the same way
that a language belongs to its speaker community. The job of the
standardiser is to provide tools for expression: attempts to define
rules that limit the expression will fail anyway, so are pointless.

        /|
 o o o (_|/
        /|
       (_/



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:48 EDT