Vjeran Marcinko wrote:
Is there a way to use more tipical
(better?) procedure, practiced by most other libraries that generate
some kind of content (JDOM, JFreeChart....) :
1. Create Document
2. Add content
3. Create PdfWriter using OutputStream
4. Write Document using PdfWriter
In other words, you want Document to act as some kind of OO model of the
document data, so that it can be arbitrarily written to a specific output
location on demand. If that's what you want, then iText's document can't do
it. However, it would be fundamentally easy, even if a bit work intensive,
to create something to do exactly that. All you'd have to do is duplicate
Document's public API and store each method call and its parameters in a
list, and then replay those actions on demand later. In fact, you could
probably build something with a little creative use of
java.lang.reflect.Proxy that would prevent the grunt work from happening.
I'm glad that iText doesn't work this way intrinsically. If it did, then
there would be no way to write very large PDF documents using iText, since
all the data for the document would have to reside in memory at one time.
The same is true with one of your examples, JDOM. Any DOM variant is
well-known to be suitable only when the data is not going to be very large,
and SAX is provided as an alternative for parsing extremely large XML
documents. (JFreeChart need not worry because the amount of data that can
be represented on a graph is very small.)
That way Document would only mean encapsulation of content, without
mixing it's meaning with generation. I want to create a "service"
object that would generate PDFs from passed content, which would best
be encapsulated as Document object, but that means that all elements
should already be added to passed Document instance, *before* PDF
generation takes place.
So you want your service objects to be aware of iText? In that case, why
not just pass them a Document instance after you've added the listener, and
let them write to it then. The only situation where you'd need the above is
if you wanted to examine the contents of the document programmatically
(which is well beyond the scope of iText), or if you didn't find out which
output format you want until you're nearly done writing the data (which is
an odd requirement indeed).
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
