xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Question for new projects
Date Sun, 20 Jan 2002 11:01:53 GMT
Arved Sandstrom wrote:
> -----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
> [ SNIP]
> <stefano>
> 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
> community.
> Arved, any info about MathML on the FOP side of things?
> </stefano>
> 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.

I totally agree with your vision.

My personal goal has always been the one to make Apache *the* place for
digital publishing on any media and for any needs.

It might takes decades for us to get there, but hey, I'm very patient
and TeX was created with a much poorer language (web, a pascal clone)
with a much smaller working group, in an age where open development
wasn't established but with very close scientific communities.

If you think that jakarta.apache.org and xml.apache.org are just a few
years old, I think the only thing that can stop us is collapsing under
our own weight.

This is the reason why we are extremely cautious about starting new
projects, but I'm confident that with better community tools (and this
is why Sam and I want Forrest so bad!) and with more solid community
practices, we'll be able to scale more and to reach the goals that we

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche

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