[
Lists Home |
Date Index |
Thread Index
]
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)
|
