-----Original Message----- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: January 19, 2002 5:50 AM To: [EMAIL PROTECTED] 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. Regards, Arved Sandstrom --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
