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

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

From: Robert Miner <robertm@dessci.com>
Date: Fri, 27 Jun 2008 07:59:34 -0700
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD603647D64@franklin.corp.dessci>
To: <Justus-bulk@Piater.name>, <dev-tech-mathml@lists.mozilla.org>, <www-math@w3.org>


This is a perennial problem area.  It is a general problem affect a
class of character that I personally call "pseudoscripts".  Prime is the
main one, but it also affects

asterisk (x2a)
degree (xb0)
prime (x2030)
double prime (x2033)
back prime (x2035)

In all of these cases as you note, the standard glyphs in most fonts are
"pre-shrunk and pre-raised", i.e. the glyph is visually congruent with
script-sized text, and the metrics for the characters place the natural
baseline of the glyph at the script baseline for the surrounding text.

The rationale is obvious -- the majority of use of fonts is in
unstructured text where characters are simply placed next to one
another, so pre-shrinking and pre-raising these glyphs gives the desired
typesetting in simple text editing situations.

However, there are a couple of issues.  First, these characters are
frequently used in situations where the typesetting effect of "stacked"
scripts are needed, i.e. where both a superscript and subscript are
attached to a single base expression.  In TeX, x^\prime_0, or in MathML
<msubsup> <mi>x</mi> <mn>0</mn> <mo>&prime;</mo> </msubsup>.  This is a
fairly strong requirement for professional publishing, and isn't not
easily supported using the Unicode-only model.  That is, neither of


gives the desired result.  A second issue is the (admittedly weaker)
argument that marking the prime with a script better reflects its role
as an operator applied to an expression.  This argument is most
compelling with expressions like (f+g)', where you would end up with
<mo>)&prime</mo> in the juxtaposition model.

Finally, this question has been considered repeatedly over the lifetime
of MathML, and at least the Math WG has always come down on continuing
the practice of marking primes and the other pseudoscripts with script
markup.  So there is backward compatibility to consider, since that is
what most authoring tools and pre-existing content now do.

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.

Consequently, I have concluded that there is no alternative for
high-quality MathML renderers but to special-case the handling of
pseudo-script characters.  

There are a couple of standard approaches I know of in various
implementations.  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.  Once a special case has been identified,
then there is a choice.  If the renderer can compute the true bounding
box of the glyph, then it can select an appropriate size and position
the standard glyphs for these characters from whatever font is
available.  However, I know of other renderers that make use of
non-standard private glyphs for "on baseline" versions of these
characters.  The most notable is the full-size, on-the-baseline version
of the prime character in the TeX fonts you allude too.  This tends to
be a more popular approach is large publishing operations that use
non-MathML-based typesetting engines such as XyEnterprise's XPP engine,
where MathML support is provided by pre-processing markup into a
proprietary math typesetting language.  In this case, special casing the
layout algorithm is difficult or impossible, and thus swapping out
different glyphs is the more practical.

I hope this is helpful.


> -----Original Message-----
> From: dev-tech-mathml-bounces+robertm=dessci.com@lists.mozilla.org
> [mailto:dev-tech-mathml-bounces+robertm=dessci.com@lists.mozilla.org]
> On Behalf Of Justus-bulk@Piater.name
> Sent: Thursday, June 26, 2008 12:12 PM
> To: dev-tech-mathml@lists.mozilla.org; www-math@w3.org
> Subject: Rendering primes: <msup><mi>x</mi><mo>&#x2032;</mo></msup>
> Hi -
> I'm slightly confused about proper markup and rendering of primes.
> The W3C appears to recommend that primes be marked up as superscripts,
> as shown in the subject line. This gave the expected results in
> Mozilla back when I still used the LaTeX XFT fonts. That's normal: The
> glyph used for the prime, codepoint U+0030 in cmsy10.ttf, is an
> oversized, vertically roughly centered slab that is scaled and shifted
> into just the right position and size by virtue of the superscript.
> However, Unicode fonts these days provide a glyph (at U+2032) that is
> quite evidently designed to be used without superscripting; its
> position and size correspond to apostrophes and quotation marks. Using
> the above markup, it is thus rendered too small and too high above the
> baseline. (To see what I mean, point your out-of-the-box,
> STIXBeta-powered Firefox3 to
> http://www.w3.org/Math/testsuite/mml2-
> testsuite/Topics/Primes/primes1.xml
> and compare the first x-prime to its sample rendering.)
> So there is, I think, a contradiction between the recommended MathML
> markup and the reality of glyphs.
> As far as solutions are concerned, I think that W. Hammond's
> suggestion
> (http://www.albany.edu/~hammond/gellmu/primeaccents2.xhtml#mi) has its
> merits. But if we stand by the <msup/> convention, then MathML
> renderers will have to treat superscripted primes differently than
> other superscripted characters.
> Justus
> _______________________________________________
> dev-tech-mathml mailing list
> dev-tech-mathml@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-mathml
Received on Friday, 27 June 2008 15:00:18 UTC

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