New Draft of SVG Spec

Wednesday April 28th, 1999

There's a new draft of the Scalable Vector Graphics spec at the W3C. Thanks to Matt for the news.

#1 Re:New Draft of SVG Spec

by Steve Jobs

Thursday April 29th, 1999 11:16 AM

Reply to this message

Great... another standard that people can whine about their browser not supporting.

#2 Re: New Draft of SVG Spec

by David Baron <>

Thursday April 29th, 1999 11:50 AM

Reply to this message

SVG is still very early in its draft stages, and it's nowhere near ready to be implemented yet. There are still large parts that aren't written yet.

#3 Re:New Draft of SVG Spec

by Bill Gates

Thursday April 29th, 1999 11:55 AM

Reply to this message

Another standard for me to "extend and embrace"

#4 Re:New Draft of SVG Spec

by Matt N.

Thursday April 29th, 1999 12:00 PM

Reply to this message

Although it says its a draft, they are inviting people to try and implement it. However, they also state that it is not complete and may well change.

I have to say they this would be very very useful to me, so would love to see an early implementation to see what could be done.

#5 Re:New Draft of SVG Spec

by Dave Fiddes <>

Thursday April 29th, 1999 12:25 PM

Reply to this message

I've seen a few messages about this on the NGLayout newsgroup. to be honest nobody seems interested at the moment. There haven't been any hints even from Netscape guys as to where to look to include SVG-like functionality into the layout engine. I'm interest in adding MathML support which is similar to SVG but smaller and it's been a recommendation for ages... same lack of interest.

I guess the Netscape guy's are working hard to finish Gecko 1.0....

#6 Re: New Draft of SVG Spec

by qwertyuio

Thursday April 29th, 1999 1:06 PM

Reply to this message

Wouldn't it be a great chance to try the improved expandibale IMLIB

#7 Re:New Draft of SVG Spec

by Roger B. Sije <>

Thursday April 29th, 1999 3:51 PM

Reply to this message

I was pleased to read the snippet of David above. At last, here is someone willing to implement MathML and let the world see its full glory! Putting documents on the web is a cumbersome task for us in the scientific community. Imagine *several gifs per line* to represent the various formulas. Modifying/Maintaining them is a time-consuming exercise that involves many genuflexions. They clutter and make the document slow to download. Moreover, no matter how many tricks you use, their look leaves a lot to be desired.

But with people like David, we may start dreaming of enjoying MathML soon :-)

In a related thread here at MozillaZine, an explanation of the delay in MathML/SVG was given (see quotation below). It appears that the delay arises from the fact that the frame and style APIs are not yet stable and thus are not made public. Perhaps if David formally joins the team of developpers of Mozilla, he may get the privilege to access to the current APIs and start hacking something... Is our wait over ?!

[QUOTE]Re:M4 Out! submitted by Nisheeth Ranjan Tuesday April 20th, 1999 04:56:20 PM

MathML is going to need support for allowing third party frame objects to plug into Gecko. This support for extensible frames will need us to expose our frame and style APIs to the outside world, something that we do not want to do before they are more fleshed out. We know that development of MathML and SVG is blocked on this task and that this is a significant problem. We plan to attack this problem once Gecko 1.0 is feature complete.

Nisheeth -- Gecko Team Member (XML, Layout, Webshell), Netscape [/QUOTE]

#8 Re:New Draft of SVG Spec

by Roger B. Sidje <>

Thursday April 29th, 1999 4:07 PM

Reply to this message

Of course, I meant Dave, Dave Fiddes, in my piece above.

#9 Re:New Draft of SVG Spec

by Roger B. Sidje <>

Thursday April 29th, 1999 4:07 PM

Reply to this message

Of course, I meant Dave, Dave Fiddes, in my piece above.

#10 Re:MathML/SVG

by Dave Fiddes <>

Friday April 30th, 1999 7:28 AM

Reply to this message

Ahh. That explains it...

I was wondering why there had been no response. There was some talk a while back over exposing the internal frame interface such that 3rd party frame objects could be integrated into the layout engine but nothing seemed to come of it.

AFAIK The frame APIs that Nisheeth is talking about have not been written yet... that standard stuff is of course there for perusal ;) I've spent a while this week trying to fathom how the layout engine does it's work...and it's quite obvious that theres a lot going on in the layout engine. Anything that I or anyone else did would be at the mercy of major NG Layout code tidy ups....

By the time I'm "unblocked" I might have put together enough time to understand how the layout engine works...

Dave, David - I'm easy ;)

#11 Re:New Draft of SVG Spec

by arielb

Sunday May 2nd, 1999 1:56 AM

Reply to this message

most users don't need MathML. I doubt IE or Opera will ever support it. Mozilla will because open-source is so cool. I have a website that could use mathML and it would be nice if it can be viewed by a popular browser such as Netscape as opposed to an obscure one that only a few people have. Anyway, once mozilla gets mathML it will _own_ the academic/scientific community. :)

#12 Re:New Draft of SVG Spec

by Brendan Eich <>

Sunday May 2nd, 1999 5:14 PM

Reply to this message

MathML fans, what do you think of Dave Raggett's EzMath (<>)?


#13 Re:New Draft of SVG Spec

by Roger B. Sidje <>

Sunday May 2nd, 1999 5:34 PM

Reply to this message

It is true that most users don't need MathML. Interestingly however, the rest, i.e those that will need it, is not a negligible part either.

Most users are on Windows yes, but Linux users are currently estimated at about 7 millions...

The academic/scientific community is spread over all flavors of *nix/Windows and is even greater. An emerging concept dubbed "flexible delivery" is taking shape within universities. It goes further than just dumping teaching materials on the web with ugly and cumbersome math.gif :-) It involves interactive distance learning, online examinations and marking, etc. With MathML will come such things as "scientific chat", "scientific message boards" where formulas in plain text (using a language called TeX) are sent flying over the net, converted in MathML, and displayed nicely and meaningfully, thus enabling more fruitful and enjoyable messaging between students, teachers, and researchers.

We are eagerly awaiting MathML.

#14 Re:New Draft of SVG Spec

by Roger B. Sidje <>

Sunday May 2nd, 1999 8:52 PM

Reply to this message

Thanks Brendan for pointng us to that effort. I have just read it, quoting from that page, I now understand that "EzMath provides an easy to learn notation for embedding mathematical expressions in Web pages. It is inspired by the way you would speak an expression if you were asked to read it over the phone." For example, EzMath will parse the plain text "a plus b equals c" to display and/or render the MathML code for "a+b=c".

That's fine. But the problems are:

* it is a plug-in. Math is not just an embedded music icon, or the big rectangle of a java applet sitting somewhere on the screen. So the alignment/font/size often doesn't match and blend gracefully with other parts of the page. There is an instructive comparison and review about this <>

* EzMath covers only a limited set of math formulas

* the worse of all, it cannot (yet) take the MathML code itself as input.

Having said this, it is however worth noting that the focus is on the merits of a native/built-in support of MathML within Gecko, not on the merits of a particular plug-in that one has to download and then write the math expressions in a certain manner. If the Gecko lizard can directly chew MathML, it doesn't matter which tools was used to generate the MathML code in the first place.

What I find very interesting in EzMath is that it may actually be used to reverse engineer MathML and obtain a natural language transliteration of cryptic MathML content tags, e.g. an English rendition of a MathML code. But that's another story.

Personally, rather than using the verbose syntax of EzMath, I am inclined to use LaTeX/TeX (written by D. E. Knuth, the guru!) and leave the task of converting from TeX/LaTeX to MathML to an auxiliary tool. In fact, with the yet another great mozilla idea of the "Transformation Services", if one is more at ease with TeX/LaTeX, one just can copy-paste the plain TeX/LaTeX text (or the EzMath text for that matter) in the HTML text, then let the client do the conversion on the fly in MathML (with a third party tool), before feeding the Gecko lizard with the whole lot.

Hence it is the built-in support of MathML within Gecko that is essential. The rest is incidental.

#15 Re:MathML

by Dave Fiddes <>

Monday May 3rd, 1999 5:30 AM

Reply to this message

My group(<>) has a set of libraries that can take an equation e.g. y=3sin(2z)/(w+1) and convert this into its MathML content markup....we can also do the reverse provided the MathML uses only *content* markup rather than presentation markup.

It's all under development at the moment but we might be able to release a simple tool for producing MathML for web pages. Unfortunately due to commercial restrictions it will not be Open Source :(

#16 Re:New Draft of SVG Spec

by Roger B. Sidje <>

Monday May 3rd, 1999 5:57 PM

Reply to this message

There are other free open source alternatives. In the W3C Math Recommendation <> one can read "a priority in the design of MathML was the ability to convert TeX math input into MathML format. The feasibility of such conversion has been demonstrated by prototype software."

#17 Re:New Draft of SVG Spec

by arielb

Monday May 3rd, 1999 6:15 PM

Reply to this message

maybe someone could set up a mozilla mathml webpage so that this project could be organized and presented to the public

#18 Volunteer to own MathML project for

by Eric Krock <>

Monday May 3rd, 1999 10:11 PM

Reply to this message

The $2^6 question: is there anyone willing to step up and assume ownership of a MathML project home page on This could start to pull interested people and resources together in one place, even if we don't have enough C/C++ implementors involved at the outset. If interested, email me. Thanks!