[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SUMMARY #1] Why is there little usage of XML on the 'visi
David Carlisle said: >> --text follows this line-- >> The advantages of unified framework are inmense. For instance, instead >> using SVG for graphics and p-MathML for mathematics one prefer an all >> SVG approach. > > hmm, perhaps, but now, today, If you use MathML you can just "cut and > paste" mathematical expressions from popular browsers (IE, firefox, in > particular) and drop the expressions into popular mathmatical packages, > (maple, mathematica) and have the expressions understood as > mathematics. In how many cases? How you know i did an experiment about that this year. I generated MathML code for \dot{q} using several MathML tools (ORCCA, IteX, ASCIIMath) and next submited the MathML code to online Mathematica 5.2 and two were rejected offering errors and other was incorrectly interpreted. It was a simple \dot{q} not a complicated two-lines quantum equation in L-space. > The SVG may (see below) render OK but as far as any further > processing is concerned is likely to be essentially the same as an > image. Of course a browser that has SVG rendering capability (whether as > part of the core code or as a plugin of some sort) may use SVG > internally to render all sorts of things, including MathML, but that > doesn't negate the benefits of serving the Math-specific markup to the > client. Use content markup for the encoding of the math, SVG for the rendering. For instance instead supporting OpenMath + c-MathML + p-MathML + SVG, browers would prefer OpenMath + SVG instead duplicating again and again the same code (this is a real point against real lack of support for XML nobody addresed still in this list). > The document author doen'st need to know what rendering > technology will be used to read the document. The document might last > 1000 years, it's unlikely that the processing pipeline used to render it > will last that long. > > >> In that case any SVG browser can render math without need for >> native supprting MathML. > > SVG may render OK at a particular window size but it's hard to see how > automatic line breaking would work in that case (as it happens today in > a limited extent in mozilla) given an SVG encoding of a particular > layout. SVG's very good at what it's good for, but it isn't designed > for, and isn't particularly good at, expressing an inline mathematical > expression that has to take part in the paragraph flow and line breaking > of the surrounding text. Then add one or two small modifications at the SVG place or better still add the funcionality on the content markup + browser layer instead waiting a full spec was spreaded over browsers in a magical way. Your emphasis on inlines and baselines remember me your few days ago (in another site) statement that CSS rendering i was promoting could not align to baseline as specific MathML markup could do. I cited a link with technical data and examples and George provided you a specific piece of CSS doing just you claimed days before could be _not_ done. Well, there is also ways to inline adjust in a XSL-FO and in a SVG rendering approach. Moreover, let me also note that whereas i like the posibility for automatic line breaking of math code, most of the MathML code is being served on the web cannot benefit from 'thanks' to scary code as <msup><mrow/><mn>2</mn></msup><mi>F</mi> or <math><mn>2</mn><mo>(</mo><mi>a</mi><mo>+</mo><mi>b</mi><mo>)</mo></math> > David > Juan R. Center for CANONICAL |SCIENCE)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|