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

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

From: <Justus-bulk@Piater.name>
Date: Sat, 28 Jun 2008 11:52:05 +0200
To: "Robert Miner" <robertm@dessci.com>
Cc: <dev-tech-mathml@lists.mozilla.org>, <www-math@w3.org>
Message-ID: <x8tlk0pq43e.fsf@tool.montefiore.ulg.ac.be>

Robert -

Thanks, your comments did shed additional light on this issue, at
least for me.  The arguments in favor of treating primes (and similar)
as superscripts are compelling.

It seems to me that a clean and simple solution would be for a
renderer to create private glyphs from pre-scripted glyphs by applying
the inverse scripting transform (which should not require any
knowledge beyond that already needed for the forward transform), and
then blindly substitute these for the originals.

This should yield the expected results for all typical use cases
conformant with W3C markup conventions, including multiple characters
within the scripted token element, but would break non-standard markup
such as this:

"Robert Miner" <robertm@dessci.com> wrote on Fri, 27 Jun 2008 07:59:34
-0700:

> 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.

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, but this heuristic breaks down with nested/chained
superscripts.

W3C folks: It would be nice to include a clarification on markup
conventions and rendering expectations in the MathML specs or
accompanying docs, since these are clearly in conflict here. A
suggestion for MathML 3?

Mozilla folks: what do you think? Shall I open a bug with the above
suggestion for a fix?

Thanks,
Justus
Received on Saturday, 28 June 2008 09:52:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:13:01 GMT