Hi Jason, yes, generating a SAX stream from JAXB should be easy. But personally, I would never write Java code that produces XSL-FO for real-life documents because it would be too tedious and very hard to maintain. In every single case, I would see to it that I can produce XML data and put that through an XSLT stylesheet.
Looking at the generated JAXB classes from the plutext SVN repo, I can see how all inheritable properties have to be repeated for each and every FO object. Jason, have you thought about how much memory each of these objects consume? Most of them will not ever be set so are just wasting space. I really think this approach doesn't make sense. You would at least be a little better off doing some code generation of your own to provide Java interfaces and FO object classes that are operating on an XML DOM as backend. That way, you'd have a sparse approach to these objects. You might even want to investigate directly working with FOP's FO tree. On 19.11.2010 11:59:20 Peter Hancock wrote: > Hi Jason, > > I can imagine your motivation for creating a representation of an fo > tree in a java application > however feeding this into FOP directly would perhaps be a little > wastful from FOP's point of view: > FOP uses SAX to parse the fo input and then builds an internal > representation of the FO tree. > This is not just a deserialization of the tree into java beans- > the FO Tree classes provides methods that capture the semantic > complexity of the fo structure, > one that cannot be represented in an .xsd. > > Navigating a DOM like structure and then generating the richer FOTree > would promote an extra layer of processing > and memory consumption, and is something we would want to avoid when > dealing with large documents. > > This is not to say there is no value with your approach to generating > fo. Maybe you could navigate your tree and generate sax events > that can be handled by FOP's FOTree builder- I think this can be > achieved in fairly straigt forward way, although I am no expert in > chaining SAX processors. > Perhaps a bit of bridging code maybe required and perhaps FOP would > benefit from this. > > Hopefully some one else in the FOP community can confirm my thoughts > here with perhaps a pointer for getting started. > > Pete > > > On Fri, Nov 19, 2010 at 4:35 AM, Jason Harrop <jhar...@gmail.com> wrote: > > Hello > > > > I have used the JAXB tool XJC to generate a set of classes which > > represent > > http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/foschema/fop.xsd > > > > As wikipedia explains, "Java Architecture for XML Binding (JAXB) > > allows Java developers to map Java classes to XML representations. > > JAXB provides two main features: the ability to marshal Java objects > > into XML and the inverse, i.e. to unmarshal XML back into Java > > objects". JAXB is similar to XMLBeans. It is JSR-222. > > > > You can see the Java classes for fop.xsd at > > http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/xslfo/org/plutext/jaxb/xslfo/ > > > > My motivation was initially to be able to create somewhat complex > > layout master set; see > > http://dev.plutext.org/svn/docx4j/trunk/docx4j/src/main/java/org/docx4j/convert/out/pdf/viaXSLFO/LayoutMasterSetBuilder.java > > > > I'm planning to publish the code somewhere as a code base independent > > from docx4j. Is there any interest in having it as part of FOP? > > > > What if FOP could ingest these Java objects directly (ie without the > > having to be marshalled first)? > > > > If there is no interest, that's fine. I'll just put the code on > > Google Code, say. > > > > cheers . Jason > > Jeremias Maerki