Open
Bug 297465
(mglyph)
Opened 19 years ago
Updated 1 year ago
Add support for mglyph
Categories
(Core :: MathML, defect)
Tracking
()
NEW
People
(Reporter: mmokrejs, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-needed, helpwanted)
Attachments
(5 files, 4 obsolete files)
2.00 KB,
text/html
|
Details | |
939 bytes,
text/html
|
Details | |
12.39 KB,
patch
|
Details | Diff | Splinter Review | |
4.99 KB,
patch
|
Details | Diff | Splinter Review | |
14.86 KB,
patch
|
Details | Diff | Splinter Review |
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: http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mglyph/rec-mglyph2.xml Reproducible: Always
Comment 2•19 years ago
|
||
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: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 3•18 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → EXPIRED
Reporter | ||
Comment 4•18 years ago
|
||
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
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Reporter | ||
Comment 5•17 years ago
|
||
Still an issue with current trunk build.
Reporter | ||
Comment 6•17 years ago
|
||
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
Comment 7•15 years ago
|
||
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/> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter3.html#id.3.2.9.4
Updated•15 years ago
|
QA Contact: ian → mathml
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: mglyph not shown at all → mglyph not shown at all (not implemented)
Comment 8•14 years ago
|
||
Updated•14 years ago
|
Assignee: rbs → nobody
Comment 9•14 years ago
|
||
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.
Keywords: helpwanted
Updated•14 years ago
|
Alias: mglyph
Comment 10•13 years ago
|
||
Some reftests based on those from the MathML testsuite: http://devel.mathjax.org/testing/testsuite/MathMLToDisplay/Presentation/TokenElements/mglyph/ (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)
Updated•12 years ago
|
Keywords: dev-doc-needed
Comment 11•12 years ago
|
||
(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...
Updated•12 years ago
|
Assignee: nobody → fred.wang
Summary: mglyph not shown at all (not implemented) → Add support for mglyph
Comment 12•12 years ago
|
||
Attachment #406853 -
Attachment is obsolete: true
Comment 13•12 years ago
|
||
Comment 14•12 years ago
|
||
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...
Attachment #586464 -
Attachment is obsolete: true
Attachment #587843 -
Flags: feedback?(jonas)
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. ::: content/mathml/content/src/nsMathMLMglyphElement.cpp @@ +100,5 @@ > + return rv; > +} > + > +nsresult > +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.
Attachment #587843 -
Flags: feedback?(jonas) → feedback+
cc'ing roc and dbaron to get input on if this is a feature that we want to implement.
Comment 17•12 years ago
|
||
Why was it deprecated and why is it something we want to implement? (Are downloadable fonts a better solution here?)
Comment 18•12 years ago
|
||
(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. http://www.w3.org/TR/MathML2/chapter3.html#presm.mglyph 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." http://www.w3.org/TR/MathML3/chapter3.html#presm.mglyph 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.
Comment 19•12 years ago
|
||
(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.
Comment 21•12 years ago
|
||
Attachment #586463 -
Attachment is obsolete: true
Comment 22•12 years ago
|
||
Comment 23•12 years ago
|
||
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.
Updated•12 years ago
|
Status: NEW → ASSIGNED
Updated•12 years ago
|
Assignee: fred.wang → nobody
Updated•12 years ago
|
Attachment #587843 -
Attachment is obsolete: true
Comment 24•12 years ago
|
||
Comment 25•12 years ago
|
||
Comment 26•12 years ago
|
||
Comment 27•12 years ago
|
||
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.
Updated•12 years ago
|
Status: ASSIGNED → NEW
Comment 28•11 years ago
|
||
(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 > elsewhere? 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. https://bugs.webkit.org/show_bug.cgi?id=100626 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.
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•