Bug 108778 - Add support for mathvariants that cannot be emulated via CSS
 Summary: Add support for mathvariants that cannot be emulated via CSS
 Depends on: Blocks: Status: NEW Product: WebKit Component: MathML Version: 528+ (Nightly build) Platform: Unspecified Unspecified Importance: P2 Normal Assigned To: Martin Robinson URL: Keywords: 85735 Show dependency tree / graph

 Reported: 2013-02-03 16:36 PST by Martin Robinson Modified: 2013-09-30 02:04 PST (History)

Attachments
Patch (26.58 KB, patch)
2013-02-03 16:48 PST, Martin Robinson
no flags Review Patch | Details | Formatted Diff | Diff
Try to fix the Mac build (26.59 KB, patch)
2013-02-03 17:21 PST, Martin Robinson
no flags Review Patch | Details | Formatted Diff | Diff

 Note You need to log in before you can comment on or make changes to this bug. Description From 2013-02-03 16:36:15 PST Some mathvariant choices cannot be emulated via CSS, so they must be implemented via character replacement. These include double-struck, Fraktur, bold Fraktur, script, and bold script. ------- Comment #1 From 2013-02-03 16:48:21 PST ------- Created an attachment (id=186277) [details] Patch ------- Comment #2 From 2013-02-03 17:00:00 PST ------- A few notes to reviewers about this patch: First, this is all quite new to me, so I wouldn't be surprised if the patch is wildly wrong. Apologies in advance and thanks for any guidance you can give me! The use of DOM replacement here isn't ideal, since it's a one way transformation. If JavaScript changes the mathvariant attribute, then the change won't be reflected properly. It seems that the way to handle this case properly is to create a RenderMathMLText and have it reflect the transformed text. To be completely honest, I took this approach initially as it's a similar situation to CSS text transformations. The issue is that in the case of MathML mathvariant, the transformation is from characters in the BMP to out of the BMP. In practical terms this means that the UTF-16 encoded text value of the RenderText will be a different length than the DOM string (non-BMP characters can take two UTF-16 code units). This causes havoc with the Range and TextIterator classes, leading, for instance, to corrupted paste data. The issues with Range and TextIterator are probably solvable issues (and probably should be solved), but as I was looking at it, I noticed a startling large amount of yak hair accumulating on the floor. I went instead with this simpler approach that was less correct. The other thing to notice about this patch is that I did not do mappings for transformations that are now handled via CSS. I hope to do that in a future patch. I see mapping even CSS-emulatable mathvariants as a good thing, because it means that you can copy and paste while maintaining some semantic meaning. The MathML spec stresses that mathvariant carries semantics. Finally, judging by https://bugzilla.mozilla.org/show_bug.cgi?id=449396 it seems that the mathvariant attribute shouldn't be inherited. This is reflected in my patch. It doesn't look like we support mstyle yet. ------- Comment #3 From 2013-02-03 17:19:25 PST ------- (From update of attachment 186277 [details]) Attachment 186277 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/16355890 ------- Comment #4 From 2013-02-03 17:21:48 PST ------- Created an attachment (id=186282) [details] Try to fix the Mac build ------- Comment #5 From 2013-03-04 11:52:03 PST ------- (From update of attachment 186282 [details]) Clearing the review flag. Daniel and I talked about this patch and my approach is indeed problematic. ------- Comment #6 From 2013-03-14 02:30:43 PST ------- To follow-up yesterday discussion and for the record: - I have the impression that the attribute is still used a lot. I asked to the LaTeXML folks to directly use the Unicode code point but MathJax still relies on mathvariant. So that's why this is blocking the MathJax tracking bug :) - As Martin said above, mathvariant is available on too. Although I think most of mstyle should be removed (http://lists.w3.org/Archives/Public/www-math/2012Sep/0002.html) I believe mstyle@mathvariant is actually one of the attribute used in real content. - Like Neil and David said, some characters are invariant to italic change for example U+210E (PLANCK CONSTANT) and the italic style should not be applied to them. Similarly, style="font-weight: bold;" should in theory not apply to e.g. fraktur letters. - MathJax and Gecko "implements" this via CSS using different fonts. So instead of remapping the Unicode code point, they change the style (italic, bold, font-face). That could be a temporary solution. See http://mxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css#124 As Dave said, I plan to implement that in Gecko using a private -moz-mathvariant CSS property. Basically, the mathvariant attribute on mstyle and token elements will be mapped to this property and then the text rendering code will use that property to choose the right transform to perform. So I agree with you that this is related to the italic mi issue and could be handled the same way. ------- Comment #7 From 2013-09-30 02:04:31 PST ------- (In reply to comment #6) > As Dave said, I plan to implement that in Gecko using a private -moz-mathvariant CSS property. Basically, the mathvariant attribute on mstyle and token elements will be mapped to this property and then the text rendering code will use that property to choose the right transform to perform. So I agree with you that this is related to the italic mi issue and could be handled the same way. FYI, James Kitchener has taken over my work and is currently implementing that via -moz-mathvariant CSS property and text transformations: https://bugzilla.mozilla.org/show_bug.cgi?id=114365