> -----Original Message----- > From: [EMAIL PROTECTED] >
Hi, <snip /> > my questions : > 1. would it be better if I use iText for large documents,... pick up the > data directly from database.... It could well be (depends on your code, anyway :) ) Downside of course is maintenance of this piece of software. Maybe there are a few standardized solutions out there that fit your description, I'm not sure. > 2 my friend told me, that I should use rather DOM file than XML > file,it will be faster...is it true ? Yes, but ... DOM first has to create an object structure representing the document in memory, so can be quite a mem-eater if the source XML is large (--on top of that: creating the document representation also has its cost) The advantages of DOM over SAX depend largely on what you actually need to extract from the source XML, whether you need repeated access to the same nodes etc. For as far as I understand FOP's processing model: SAX is used to parse the input XML (FO), and the generated SAX events are caught and mapped to an object-tree. ( Each SAX event creates a certain type of object in the FOTree ) In essence, all the FO nodes in the source document are accessed only once, namely to create an FObj representing it. IIC, this makes using a DOM input source rather suboptimal, since first the DOM representation must be created, and then that tree is used merely to create another tree --anyway, the nodes are accessed only once... Don't get this the wrong way: DOM might be useful for the source XML to the XSL transform which creates the FO, especially if you need to transform the same XML document multiple (make that: numerous) times. > 3. have u guys any idea, what is the best solutions, to generate > PDF from a large database, and that's "on the fly".. > Hmm... XSL-FO is designed exactly to serve purposes like this. That being said: is it actually FOP's processing that takes a long time, or is it the XSL transform? Can you test this a bit maybe? Run the XSL transform separately (preferrably also through another processor than Xalan to compare results). Just adding this, because I know out of experience that 'newbie' code can easily drain an XSLT processor's resources. Things like double forward slashes ( '//*' ) might seem 'handy' in being able to retrieve a node from any context in the stylesheet, but an explicit XPath expression pointing at exactly the right node saves the processor a few (--possibly quite a few) unnecessary tree traversals. Also, could you do a bit more research on whether it is the context of the servlet that creates the delay? Try rendering the same XML+XSLT via the command-line, and see if there's any noticeable difference... Hope this helps! Greetz, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
