I think that the problem was the use of the same file to read and write.
Ah, yup - I could see that as a problem...
> Do you read the entire stream into memory and then write itback out, or do "block" I/O? And why modify/read ANY object (as an
The streams are not read, only the offset in the file and the length is kept. Writing is done by block copying from file to file.
Excellent!
It's in this cases and many others that I miss C and my beloved pointers.
No question!
The big problem is that parsing is still needed and that's where the bottleneck is. I take 60 seconds to read pdfreference.pdf but only 5 to write it. The memory usage is always low as the streams are not kept in memory.
Interesting. I wonder if that's the tokenizer, Java, or something else. Sounds like a good place to profile...
> Incremental update would be a GREAT addition - not just forthe Info changes, but potentially for all PdfStamper() changes...
That's not a bad idea. All that is required is a new page dictionary with the same number and several streams with the new content with the original stream intact.
Exactly. Should definitely give folks the option (like the Acrobat SDK does) to choose what type of saving (incremental or full) to do - for those that are concerned about disk space over speed.
Encryption wouldn't be possible, though.
True.
Leonard -- --------------------------------------------------------------------------- Leonard Rosenthol <mailto:[EMAIL PROTECTED]> Chief Technical Officer <http://www.pdfsages.com> PDF Sages, Inc. 215-629-3700 (voice) 215-629-0789 (fax)
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions
