Ability to MathML specific Stuff in Composer

NEW
Unassigned

Status

SeaMonkey
Composer
P3
enhancement
17 years ago
2 years ago

People

(Reporter: R.J. Keller, Unassigned)

Tracking

(Depends on: 2 bugs, {helpwanted})

Trunk
Future
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: MathML in composer → [RFE] Ability to MathML specific Stuff in Composer

Comment 2

17 years ago
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

Comment 3

17 years ago
-->brade
Assignee: beppe → brade
Keywords: helpwanted

Comment 4

17 years ago
spam composer change
Component: Editor: Core → Editor: Composer

Updated

16 years ago
Summary: [RFE] Ability to MathML specific Stuff in Composer → Ability to MathML specific Stuff in Composer

Comment 5

16 years ago
-->
Assignee: brade → composer

Comment 6

15 years ago
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

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

Comment 8

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

Comment 9

15 years ago
Created attachment 121720 [details] [diff] [review]
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

15 years ago
Created attachment 121721 [details]
screenshot
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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.

Updated

15 years ago
Blocks: 207531

Comment 17

15 years ago
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
Product: Browser → Seamonkey
:( 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

Comment 22

8 years ago
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.
Depends on: 986839
Depends on: 987028
Depends on: 145736
Depends on: 1098150

Updated

2 years ago
See Also: → bug 1065842
You need to log in before you can comment on or make changes to this bug.