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>.
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.
Created attachment 39837 [details] MathML bevelled fraction example
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.
(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.
(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!
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).
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).
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.