Summary:  Builtup (vulgar) fractions using the Unicode fraction slash (or other methods) not supported  

Product:  WebKit  Reporter:  O. Andersen <pubwebkit>  
Component:  Text  Assignee:  Nobody <webkitunassigned>  
Status:  UNCONFIRMED   
Severity:  Normal  CC:  alex, ap, emacemac7, mitz, pubwebkit, robburns1  
Priority:  P2  
Version:  528+ (Nightly build)  
Hardware:  All  
OS:  All  
Attachments: 

Description
O. Andersen
20090718 04:40:40 PDT
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>[09]+</mn><mn>[09]+</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 metadiscussion. > 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 fontlevel 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:AppleChancery4and221225thsExample.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. 