Composer should have a Add a equation or add mathml or something similar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: MathML in composer → [RFE] Ability to MathML specific Stuff in Composer
Yes this would be a nice feature! Marking future for now since we won't have time to work on this before Moz 1.0.
Priority: -- → P3
Target Milestone: --- → Future
Assignee: beppe → brade
spam composer change
Component: Editor: Core → Editor: Composer
Summary: [RFE] Ability to MathML specific Stuff in Composer → Ability to MathML specific Stuff in Composer
Assignee: brade → composer
*** Bug 201748 has been marked as a duplicate of this bug. ***
Bug 55313 is about XHTML in Composer. This bug doesn't depend on that one, but an implementation might.
With the patch in place, I can edit and save XHTML files. In particular, such files can contain MathML. Caveat 1. I've only tried out a few simple things. I doubt this is the correct long-term solution for editing XHTML in Mozilla. Caveat 2. No attempt is made to edit MathML. That's been to goal of my mathmled project (http://www.newmexico.mackichan.com/MathML/mathmled.htm), but a significant amount of work is needed to bring that code over. (I've probably messed-up the patch because I don't know how to build patches across directories. I hope it's clean what I did.)
Please break the XHTML loading/saving into a separate bug. I think this patch is not enough, though, because the composer insists on some HTML doctype AFAIK. Maybe I am wrong? You can do diff multiple directories/files in one command by simply adding the dirs at the end of the command, like this: cvs diff -u dir1 dir2 dir3 However, in your case I would just cd to mozilla, then cvs diff -u editor
Further experimentation shows that almost everything in Composer works in XHTML documents (with the patch). The only major hole is Copy/Paste and Drag/Drop. Sometimes, these appear to work, but in fact the operation causes the tag names to uppercase, breaking XHTML and MathML. Poking around, I think the content is serialized to the clipboard in a reasonable fashion, but the data is taken off with the HTML parser. Fixing this will probably involve a new clipboard format. (I don't know whether a special XHTMLeditor component is actually necessary.)
With the ongoing push towards separate applications rather than a monolothic suite, there may actually be more chance for novelties in Composer than in the other applications. I hope MathML will come to composer sooner rather than later this way. It would be killer that will give an edge to composer -- something, that even commercial editors are unlikely to have. >The only major hole is Copy/Paste and Drag/Drop. Sometimes, these appear to >work, but in fact the operation causes the tag names to uppercase, breaking >XHTML and MathML. If everything else is working really really fine, leaving aside the enthusiastic/lenient testings :-) the point above doesn't look like a big deal to me since the infrastructure is there. Specifically, it seems that an |if| is needed somewhere: if the MIME type was indeed HTML then keep the HTML serializer |else| use the XML serializer, both of which exist at present.
I don't think the HTML/XML switch is so easy. If you look at |nsHTMLEditor::ParseFragment| (in nsHTMLDataTransfer.cpp), you'll see that it creates an HTMLFRAGMENTSINK then calls the parser with MIME type "text/html". Using to the XHTML MIME type invokes the XML parser, but it fails because it wants to see an EXPATSINK. What is needed is an XMLFRAGMENTSINK, but I don't see any evidence that exists yet. Otherwise, I agree. The infrastructure is there.
Had a look and it reminded me of nsRange::CreateContextualFragment()... Looks like that code is smilar to the range's CreateContextualFragment() which doesn't work for XML too... bug 133827 comment 5 - bug 133827 comment 6.
I built a nsXMLFragmentContentSink and was able to Copy/Paste XHTML+MathML in my patched Composer. I'm not attaching a patch for this because the changes are rather widespread (a new interface is needed). nsXMLFragmentContentSink isn't all that hard anyway: just merge nsHTMLFragmentContentSink and nsXMLContentSink. It only took me about a week. ;-) Furthermore, I'm convinced that in order to do XHTML in Composer, a new nsXHTMLEditor component is needed, rather than just a few strategically placed switches based on the document MIME type in nsHTMLEditor. Again, this should be straightforward. ;-) I haven't checked whether my nsXMLFragmentContentSink is a fix for bug 133827.
For quick reference, adding dependency to bug 111514 which exposed the HTML DOM for XHTML documents served as application/xhtml+xml.
Depends on: 111514
Just as a note, getting composer to work with XHTML needs, as a first step, replacing all tagname comparisons in composer with tagname and namespace comparisons, or better yet checks for nsIContent::eHTML and tagname comparisons.
I happen to be working on a MathML editor in XUL for Composer.
Status: NEW → ASSIGNED
Assignee: composer → ajvincent
Status: ASSIGNED → NEW
:( There's hardly any work being done on Mozilla Composer, and my efforts to tie in MathML (Abacus) were largely unsuccessful. This is due to certain architectural decisions with Composer. I will be reworking Abacus in the future to work with Verbosio, a prototype XML editing architecture. -> default owner/QA
Assignee: ajvincent → composer
QA Contact: sujay
Assignee: composer → nobody
QA Contact: composer
I would be very interested in finding out if there have been any new developments in this direction on the Composer and it's capacity for working with XHTML and displaying MathML.
You need to log in before you can comment on or make changes to this bug.