W3C home > Mailing lists > Public > www-math@w3.org > June 2008

Re: Rendering primes: <msup><mi>x</mi><mo>&#x2032;</mo></msup>

From: Karl Tomlinson <w3@karlt.net>
Date: Mon, 30 Jun 2008 10:52:39 +1200
To: <www-math@w3.org>
Cc: "Robert Miner" <robertm@dessci.com>, Justus-bulk@Piater.name, <dev-tech-mathml@lists.mozilla.org>
Message-ID: <871w2f26rs.fsf_-_@blackhawk.home>

On Fri, 27 Jun 2008 07:59:34 -0700, Robert Miner wrote:

> All renderers that take on the problem have to special
> case their layout algorithms, and look for isolated pseudoscripts in the
> superscript position (or presuperscript position).  By isolated, I mean
> that there are no other characters in the same token element with the
> pseudoscript, so that <msup> <mi>x</mi> <mo>&prime;!</mo> </msup> or
> whatever is not special-cased.

I'm trying to think of the best (perhaps easiest) way to detect
these special cases, while maintaining expected behavior for the

> At the same time, clearly the data model for all MathML token elements
> is Unicode CDATA, so one cannot rule out the possibility of valid MathML
> markup containing constructions such as <mi>x&prime;</mi> or even
> <mi>x</mi><mo>&prime;</mo>.  So that has to work as expected too.

Justus-bulk@Piater.name writes:

> But what is "expected" here? If such markup is expected to yield
> superscript appearance, then one might use the original glyph at zero
> script level,

I imagine the author expects presentation similar to the normal
rendering of the Unicode characters, as you suggest.

> but this heuristic breaks down with nested/chained superscripts.

Wouldn't nested superscripts necessitate the use of msup, etc.?

What is the appropriate markup for multiple pseudoscript
characters within one superscript level?

I would have considered the characters to be separate operators
and so


which makes special case detection based on infix (rather than
postfix) form impossible.

But at

a single operator containing multiple characters is used:

    <mi> x </mi>
    <mo> '' </mo>
Received on Sunday, 29 June 2008 22:53:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:40 UTC