xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arved Sandstrom" <Arved...@chebucto.ns.ca>
Subject RE: Question for new projects
Date Sat, 19 Jan 2002 12:38:59 GMT
-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: January 19, 2002 5:50 AM
To: general@xml.apache.org
Subject: Re: Question for new projects

Keep in mind that the fact that an effort starts 'sourceforged' doesn't
mean that collaboration can't take place since day one.

Rather the opposite: I would love to see collaboration between a MathML
effort and Cocoon, FOP and Batik since all of them have something to do
with XML presentation and java and many people have expressed their
interest in publishing MathML and traslating it into SVG or similar.

So, let us know when your projects start (I would suggest starting two
different ones, one for MathML and one for the text2XML parser) and I,
for sure, will be interested in sparlking collaboration from the cocoon

Arved, any info about MathML on the FOP side of things?

I second the overall sentiments. I think once the 2 projects expose
themselves on Sourceforge then we'll be able to assess what we have there,
and start collaboration.

There are a couple of different approaches that one can consider when
looking at MathML and XSL. One is to convert the MathML to FO at the XSLT
stage, and rely on the stylesheet to produce sufficiently expressive FO, in
conjunction with math fonts, to arrive at an acceptable result.

I don't know how well this would work as a general solution and I am not
enamoured of it. I think the better solution is to use the
fo:instream-foreign-graphic and have islands of MathML in the FO stream,
just as now occurs with SVG. The essential function of the
fo:instream-foreign-graphic FO is to allow XML in another vocabulary, that
really should be treated as a unit, to be processed by another mechanism,
and return a single area to the FO area tree.

So we could have a MathML plugin that is based on Stephan's code, that
returns a MathMLArea for example. This area is opaque to FOP, although it
would be internally complex. A renderer would pass MathMLAreas off to a
component that knows how to render them. The advantage of this approach is
that it can conceivably handle all situations of mathematical typography,
and it treats the math block as a unit - semantics are retained to allow for
better treatment.

Could SVG be part of this? Absolutely. The MathML plugin could possibly
convert to SVG, and then existing processes take over. Whether or not this
is the way to do it depends on the SVG support for math. I am inclined to
think that a conversion to SVG makes more sense for web-publishing (e.g.
Cocoon) and less for print-publishing (FOP with PDF etc), but we need to
examine the problem more closely.

I think this is really interesting stuff. I think we have the potential here
for an Apache XML publishing "suite" ( loathe the word "suite" but it makes
sense here :-)), that wraps Cocoon, FOP, Batik, the supporting parsers and
processors, and brings in other plugins like MathML, and really allows for a
one-stop solution to XML publishing on paper and on the Web.

Arved Sandstrom

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message