78128 - Ability to MathML specific Stuff in Composer

Status: NEW

(SeaMonkey :: Composer, enhancement, P3)

Description

[R.J. Keller]

Composer should have a Add a equation or add mathml or something similar.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[kinmoz]

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.

Comment 3

[Kathleen :Brade]

-->brade

Comment 4

[Syd Logan]

spam composer change

Comment 5

[Kathleen :Brade]

-->

Comment 6

[rbs]

Now that the HTML DOM is exposed for XHTML documents served as
application/xhtml+xml, coupled with all those things that have been going on
(there is a XUL+JavaScript MathML Editor), the scenery is a lot different than
when this bug was originally filed. Steve Swanson made a demo of Composer+MathML.
Care to attach your screenshot & patch, steve?

Comment 7

[rbs]

*** Bug 201748 has been marked as a duplicate of this bug. ***

Comment 8

[steve.swanson]

Bug 55313 is about XHTML in Composer.  This bug doesn't depend on that one, 
but an implementation might.

Comment 9

[steve.swanson]

Attachment: experimental patch to load XHTML in Composer

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.)

Comment 10

[steve.swanson]

Attachment: screenshot

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 12

[steve.swanson]

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.)

Comment 13

[rbs]

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.

Comment 14

[steve.swanson]

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.

Comment 15

[rbs]

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.

Comment 16

[steve.swanson]

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.

Comment 17

[rbs]

For quick reference, adding dependency to bug 111514 which exposed the HTML DOM
 for XHTML documents served as application/xhtml+xml.

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Alex Vincent [:WeirdAl]]

I happen to be working on a MathML editor in XUL for Composer.

Comment 20

[Alex Vincent [:WeirdAl]]

.

Comment 21

[Alex Vincent [:WeirdAl]]

:( 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

Comment 22

[Bogdan Matican]

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.

Comment 23

[romko.b.m]

MathType 7.4.4.516 now has an option «Thunderbird» in the «Cut and copy Preferences», which works fine with Composer and Mail in that one can insert directly into «normal» sheet, not necessary in HTML code.