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>

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′</mi> or even <mi>x</mi><mo>′</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, JustusReceived on Saturday, 28 June 2008 09:52:53 UTC

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