User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050612
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050612
See this testcase too:
mglyph is not yet implemented.
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Still wrong with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051122 SeaMonkey/1.5a
./configure --disable-optimize --enable-debug='-g3 -O0' --enable-debug-modules=all --enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg --enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3 --enable-application=suite --disable-freetype2 --enable-default-toolkit=gtk2 --enable-xft --disable-gssapi
Still an issue with current trunk build.
Still an issue with current cvs HEAD build:
./configure --disable-optimize --enable-debug='-g3 -O0 -ggdb' --enable-debug-modules=all --enable-debugger-info-modules --enable-detect-webshell-leaks --disable-svg --enable-image-decoders=all --with-qtdir=/usr/qt/3 --enable-application=suite --disable-freetype2 --enable-jprof --enable-default-toolkit=gtk2 --enable-xft --disable-gssapi
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070126 SeaMonkey/1.5a
It seems that the former use of <mglyph/> (access to non-standard fonts) will be deprecated in MathML 3 and replaced by something similar to <img/>
Created attachment 406853 [details]
Testcase (with respect to MathML 3)
If someone wants to work on this, the idea is to create a new class nsMathMLmglyphFrame that inherits from nsMathMLContainerFrame. Then do as for nsSVGImageFrame (or nsImageBoxFrame, nsBulletFrame...): create a class nsMathMLmglyphListener that inherits from nsStubImageDecoderObserver. Use this class in the implementation of nsMathMLmglyphFrame to handle the image.
Note however that mglyph is a bit different from the other MathML elements: it is similar to a character and can only be child of a token element. This means that additional work will probably be needed.
Some reftests based on those from the MathML testsuite:
(use nativeMathML=true to see Firefox's rendering instead of MathJax's one: http://devel.mathjax.org/testing/testsuite/MathMLToDisplay/Presentation/TokenElements/mglyph/mglyph3-ref.html?nativeMathML=true)
(In reply to Frédéric Wang from comment #9)
> If someone wants to work on this, the idea is to create a new class
> nsMathMLmglyphFrame that inherits from nsMathMLContainerFrame. Then do as
> for nsSVGImageFrame (or nsImageBoxFrame, nsBulletFrame...): create a class
> nsMathMLmglyphListener that inherits from nsStubImageDecoderObserver. Use
> this class in the implementation of nsMathMLmglyphFrame to handle the image.
> Note however that mglyph is a bit different from the other MathML elements:
> it is similar to a character and can only be child of a token element. This
> means that additional work will probably be needed.
I'm now wondering whether it would be possible to reuse nsImageFrame...
Created attachment 586463 [details]
Created attachment 586464 [details] [diff] [review]
Created attachment 587843 [details] [diff] [review]
Patch V2 - part 1
Asking feedback to Jonas on part 1.
<mglyph/> is a MathML element which provides a mechanism for displaying images to represent non-standard symbols. So I'm trying to create a class that inherits from both nsMathMLElement and nsImageLoadingContent. I looked at how it is done for HTML/SVG elements. However, MathML is a bit different since we don't implement the MathML DOM and so don't need a DOM class for each MathML element...
I took implementation of functions from nsHTMLImageElement, I hope what I did is correct and that I did not forget anything. I'm not really sure to understand all these macros to define/implement functions and whether I should add a definition in dom/base/nsDOMClassInfoClasses.h for nsMathMLMglyphElement. So any help would be appreciated...
Comment on attachment 587843 [details] [diff] [review]
Patch V2 - part 1
Review of attachment 587843 [details] [diff] [review]:
First off, I don't really know anything about mathml, so you should check with the layout team if this is a feature that we really want to implement. I say this since it seems like it largely duplicates functionality. This is especially the case if MathML3 deprecates the element.
That aside, it really is a shame that we have to duplicate so much code in each image loading element. I'd be very greatful if you wanted to factor out more stuff into the nsImageLoadingContent class, but that's obviously something that's orthogonal to this bug.
@@ +100,5 @@
> + return rv;
> +nsMathMLMglyphElement::SetAttr(PRInt32 aNameSpaceID, nsIAtom* aName,
Rather than overriding SetAttr and UnsetAttr, it would be somewhat cleaner to just hook into AfterSetAttr. See nsSVGImageElement for an example (though that uses svg-specific image loading functions, which is not what you want to do here. Keep the function calls that you currently have).
@@ +113,5 @@
> + return NS_OK;
> + }
> + // A hack to get animations to reset. See bug 594771.
> + mNewRequestsWillNeedAnimationReset = true;
We don't use this mNewRequestsWillNeedAnimationReset hack in for example svg images, so I think we should avoid it here too.
cc'ing roc and dbaron to get input on if this is a feature that we want to implement.
Why was it deprecated and why is it something we want to implement? (Are downloadable fonts a better solution here?)
(In reply to David Baron [:dbaron] from comment #17)
> Why was it deprecated and why is it something we want to implement?
What was deprecated was the fontfamily and index attributes of MathML2's mglyph element. There is no intention to implement that functionality.
The reason given was
"Originally, mglyph was designed to provide access to non-standard fonts. Since this functionality was seldom implemented, nor were downloadable web fonts widely available, this use of mglyph has been deprecated."
MathML3's mglyph (which is not marked as deprectated) is quite different and instead uses an image to display "non-standard symbols" "where existing Unicode characters are not adequate".
> (Are downloadable fonts a better solution here?)
Downloadable fonts would have the advantage over the referenced "widely recognized image formats", "GIF, JPEG and PNG", that the glyphs scale well.
However, downloadable fonts are awkward for non-Unicode characters because it would be necessary to use the Private Use Area. The fallback mechanism would not be as good as the alt text for non-visual rendering or for when downloaded fonts are disabled.
A vector image format with mglyph seems the best approach here.
(In reply to David Baron [:dbaron] from comment #17)
> why is it something we want to implement?
I didn't answer this. The MathML spec still includes mglyph, though I don't know the use cases that motivated this. It acknowledges that Unicode characters "should meet almost all users needs". The reason it gives for mglyph is "MathML recognizes that mathematics is not static and that new characters and symbols are added when convenient. Characters that become well accepted will likely be eventually incorporated by the Unicode Consortium or other standards bodies, but that is often a lengthy process."
Frédéric, do you know of any demand for mglyph support, in MathJax or elsewhere?
Does the patch as implemented here allow us to point a mglyph src at a SVG image? That sounds like it would be ideal. I *think* that works, but we should verify before checking in.
Created attachment 601627 [details]
Created attachment 601628 [details]
I know that mglyph is implemented at least in MathJax and MathPlayer, but I don't have an example in mind where mglyph is necessary. Some people probably need it and asked to keep it, for otherwise the Math WG would just have deprecated mglyph and not converted it into the version we have in MathML3.
I tested the three patches with an SVG image and that works (I added it to testcase 1). However, they make the browser crash with testcase 2 (it looks to happen when the image are not in cached) so I'll have to work on it any further.
Created attachment 640076 [details] [diff] [review]
Patch - part 1
Created attachment 640077 [details] [diff] [review]
Patch - part 2
Created attachment 640078 [details] [diff] [review]
Patch - part 3
I don't plan to work on this in the short term and don't want to continue to unbitrot the patches. I uploaded the latest versions from my patch queue. Feel free to take the bug and finish the work on it.
(In reply to Karl Tomlinson (:karlt) from comment #19)
> (In reply to David Baron [:dbaron] from comment #17)
> > why is it something we want to implement?
> I didn't answer this. The MathML spec still includes mglyph, though I don't
> know the use cases that motivated this. It acknowledges that Unicode
> characters "should meet almost all users needs". The reason it gives for
> mglyph is "MathML recognizes that mathematics is not static and that new
> characters and symbols are added when convenient. Characters that become
> well accepted will likely be eventually incorporated by the Unicode
> Consortium or other standards bodies, but that is often a lengthy process."
> Frédéric, do you know of any demand for mglyph support, in MathJax or
There have recently been discussions in Webkit about the implementation of <semantics>. It seems that it is important for people to have some fallback images and <mglyph> or <annotation> can be used to to so. In an HTML5 environment, we can also just use our <img> element but I guess some people still want to make this fallback available with the other techniques.
I'm affraid the patches are bitrotten again and I did not get the time to see where the crash comes from. But if we continue the work on this bug, I guess we should also support image with <annotation> too and share the implementation with <mglyph>.
See also bug 745131 for <semantic> improvements.