Bug 27413 – Built-up (vulgar) fractions using the Unicode fraction slash (or other methods) not supported

• Status: UNCONFIRMED
• Component: Text

[O. Andersen]

Unicode contains only a handful of precomposed vulgar fractions (viz, ½; ⅓, ⅔;
¼, ¾; ⅕, ⅖, ⅗, ⅘; ⅙, ⅚; ⅛, ⅜, ⅝, ⅞). In particular, 16ths and 32nds, which are
frequently used with imperial units, are not included.

The preferred solution, as suggested in an e-mail [1] sent to the WhatWG
mailing list, would be to let a sequence of one or more digits 0--9 followed
by a fraction slash [U+2044] followed by one or more digits 0--9 be rendered
as a built-up fraction. This behaviour is defined in Unicode, and Unicode Technical
Report No. 20 explicitly says that this solution is appropriate for use in mark-up
languages and not only in plain text.

Ideally, digits specifically designed for use in built-up fractions should be
used when available in the font used. Otherwise, scaling normal digits to 60%
height and 65% width, as suggested in the PostScript Language Cookbook,
would seem to be appropriate as fall-back.

It should also be noted that MathML does not seem to support vulgar fractions
at all, neither as specified nor as implemented in (other) browsers.

The correct behaviour is specified in Unicode 5.0, Chapter 6 `Punctuation' [2],
Section 6.1 `General Punctuation', heading `General Punctuation:
U+2000--U+206F', subheading `Other Punctuation',  subsubheading `Fraction
Slash' (p. 154):

“Fraction Slash.

“U+2044 FRACTION SLASH is used between digits to form numeric fractions, such
as 2/3, 3/9, and so on. The standard form of a fraction built using the
fraction slash is defined as follows: Any sequence of one or more decimal
digits, followed by the fraction slash, followed by any sequence of one or more
decimal digits. Such a fraction should be displayed as a unit, such as ¾ or
$\frac34$ [vertical built-up fraction]. The precise choice of display can
depend upon additional formatting information.

“If the displaying software is incapable of mapping the fraction to a unit,
then it can also be displayed as a simple linear sequence as a fallback (for
example, 3/4). If the fraction is to be separated from a previous number, then
a space can be used, choosing the appropriate width (normal, thin, zero width,
and so on). For example, 1 + ZERO WIDTH SPACE + 3 + FRACTION SLASH + 4 is
displayed as 1¾.”

[1] <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-April/019340.html>
[2] <http://unicode.org/book/ch06.pdf>

This bug is also reported elsewhere as <https://bugzilla.mozilla.org/show_bug.cgi?id=500293>.

[Alex Milowski]

The support for beveled fractions is in MathML:

<mfrac beveled='true'><mn>1</mn></mn>2</mn></mfrac>

That should do exactly what you want.

This should be able to be implemented in the fraction
rendering support being worked on for MathML.

Trying to detect and adjust the line boxes give the recognition
of a certain Unicode character without markup surrounding that
and an associated style rule seems onerous as well as possibly 
an incorrect behavior.

[O. Andersen]

Created attachment 39837 [details]
MathML bevelled fraction example

[O. Andersen]

I am not sure I understand why you think following Unicode would be incorrect. In any case, that does not matter if it would be too onerous.

Please note (as mentioned in [1] linked to in the original bug report) that the example of a bevelled fraction in the MathML specification (added as an attachment) does not suggest that
        <mfrac bevelled='true'/>
(MathML uses British spelling, apparently) should be rendered as a vulgar fraction.

I do agree, however, that it seems reasonable to handle
        <mfrac bevelled='true'><mn/><mn/></mfrac>
or
        <mfrac bevelled='true'><mn>[0-9]+</mn><mn>[0-9]+</mn></mfrac>
as a special case and render it as a vulgar fraction, and this is probably the best option if handling the Unicode fraction slash is not feasible.

[Alex Milowski]

(In reply to comment #3)
> I am not sure I understand why you think following Unicode would be incorrect.
> In any case, that does not matter if it would be too onerous.

Because you are suggesting the before and after characters have their font size
changed without a wrapping inline.  That is certainly more than kerning two
characters.  Also, to make this work, the baseline of the before and after
characters would have to change.  That also seems more than normal placement
of line boxes for character glyphs.  The attachment point of the before and
after characters would most certainly have to be special cased.

> Please note (as mentioned in [1] linked to in the original bug report) that the
> example of a bevelled fraction in the MathML specification (added as an
> attachment) does not suggest that
>         <mfrac bevelled='true'/>
> (MathML uses British spelling, apparently) should be rendered as a vulgar
> fraction.

That's just a suggestion and used to show how a much more complicated
fraction could be rendered.  I think it is perfectly reasonable to have a single
fraction render close, if not exact, as you'd want.

Since I'm working on the MathML stuff, your request is a reasonable goal for
simple fractions involving numbers.

[O. Andersen]

(In reply to comment #4)
> (In reply to comment #3)
> > I am not sure I understand why you think following Unicode would be incorrect.
> 
> Because you are suggesting the before and after characters have their font size
> changed without a wrapping inline.  [...]

Fair enough. I do appreciate your concern and do not wish to start a meta-discussion.

> Since I'm working on the MathML stuff, your request is a reasonable goal for
> simple fractions involving numbers.

That is great!

[Robert Burns]

I'm not sure how the cocoa text system and NSText fits into the WebKit open source project, but this is really an enhancement needed in the cocoa text system. Right now some AAT fonts do the job quite nicely, but my sense is that OpenType fonts do not have the control to do this (because I haven't found an OpenType font that does it on any platform). So therefore I think with OpenType fonts it is up tot he text rendering engine to implement the Unicode fraction slash behavior. For AAT fonts this behavior can be implemented in the font, but it would be nice for the rendering engine to do so if the font doesn't have any of that intelligence.

Obviously MathML should handle fractions in the MathML way, but I do think we should be getting Unicode fractions even in plain text without any special fraction markup (including in HTML).

[Robert Burns]

Just to clarify my earlier comment, I think this bug should be treated as a Unicode bug only. A separate bug could be filed for MathML fraction support, but this bug as reported by O. Anderson is about Unicode fraction support. These two issues are kept quite distinct since the Unicode fraction approach involves using the fraction slash (U+2044), while the fraction slash will be absent from the MathML. Therefore there is no conflict between the two approaches.

It may also make sense to file a bug with Apple Radar since the Unicode fraction slash support would need to come from Apple’s cocoa text system (or any other text system used by WebKit). Specifically I think that the Cocoa Text system should provide the advanced Unicode support for layout from any font by synthesizing, if necessary, the fraction numerator and denominator glyphs and laying them out appropriately. However, more advanced fonts could provide specific fraction glyphs so that the glyph synthesis is not necessary. Finally there is an issue where AAT fonts might already provide the complete layout of the font glyphs into a complete fraction. This means that either the automatic fraction rendering has to be disabled for AAT fonts or some algorithm is needed within the cocoa text system to recognize AAT fonts that already provide font-level fractions (for example Apple Chancery provides complete Unicode support within the font, but I think that is not possible with an OpenType font. see for example, http://en.wikipedia.org/wiki/File:AppleChancery4and221-225thsExample.png).

[Alex Milowski]

In reading chapter 6 from the unicode standard, I agree that this is not a MathML related issue.  While you can build such representations using MathML, following the mapping suggestions from chapter 6 would not be implemented using the MathML code directly.  Although, such an implementation might use the MathML rendering objects for fractions.