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>

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>

Hi. 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>′</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 <msub><mi>x&prime</mi><mn>0</mn></msbub> <msub><mi>x</mi><mn>0</mn></msub><mo>′</mo> 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′</mi> or even <mi>x</mi><mo>′</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>′!</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. --Robert > -----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>′</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-mathmlReceived 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
*