This sounds like something we could really use. Please continue to develop this and by all means, get it added to the base.
Thanks, Jim Urban - [EMAIL PROTECTED] Park City Solutions Inc. Clinical Connectivity Suite Product Manager Suite 295 500 Park Blvd. Itasca, IL 60143 Voice: (630) 250-3045 x106 Fax: (630) 250-3046 CONFIDENTIALITY NOTICE This message and any included attachments are from Park City Solutions Inc. and are intended only for the entity to which it is addressed. The contained information is confidential and privileged material. If you are not the intended recipient, you are hereby notified that any use, dissemination, or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error please notify the sender of the delivery error by e-mail or call Park City Solutions Inc. corporate offices at (435) 654-0621 -----Original Message----- From: Paul Reavis [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Reavis Sent: Tuesday, May 14, 2002 1:38 PM To: [EMAIL PROTECTED] Subject: direct rendering of images to pdf I have finished the initial implementation of what I call on-the-fly images in fop. Essentially this is a callback system that has an object draw itself into a PDFGraphics2D during pdf rendering, rather than going through intermediate steps such as svg or Images. I'm fairly pleased with it, though it did turn up some other scalability problems. Initially, plotting one test map took 1.25 minutes; the new version takes about 8 seconds. The original implementation, using the standard fop distribution generated an svg (slow), then loaded the svg (slow), then rendered the svg to the pdf. The new implementation registers some callbacks for the included images, and the callbacks render directly. Memory usage is much better now, as well. We frequently overran the default 64MB with the original implementation, since the dom-based svg generation and reloading both ate up the heap. Now I can generally plot up to E size PDFs (34" x 44"), though for complex maps I still run out of heap. Looking into the implementation of PDFRenderer and PDFGraphics2D, it looks like the memory bottleneck with the new implementation is probably the fact that PDFGraphics2D stores its results in a StringWriter, and then that StringWriter is appended to the PDFStream's own ByteArrayOutputStream. This requires twice as much ram as simply writing directly to the PDFStream. True scalability, frankly, will require rendering directly to a file, and keeping as little in RAM as possible. I didn't chase the code to see how difficult that would be, but I figure it's not trivial. The benefits would be enormous - for example, I could plot an entire multi-hundred page map book. On the other hand, the ability to have PDFGraphics2D write directly to the PDFStream should be fairly easy to implement. I'm looking into this now. I did also uncover some bugs. Most prominently, PDFGraphics2D instances spawned from others using createGraphics have their own StringWriters and therefore anything rendered to them kind of disappears off into space. I rewrote it so they share the same StringWriter. In any case, I have a few major changes that may be useful. Are they, and if so should I go ahead and see about getting CVS write access, or does someone want to "sponsor" me or should I simply send a patch? I have a feeling I'll be returning to the code in the future in any case. Thanks. While I'm finding fop to be kind of a bear, it's still the only real game in town for what I'm trying to do, and I'm getting some great results - we just plotted half the state of new hampshire onto a page the size of a bedsheet, and that's not easy to do without banging your own postscript - add to that the ability to stick these plots on nicely-formatted reports with all the power of FO too and it makes my life a lot easier. -- Paul Reavis [EMAIL PROTECTED] Design Lead Partner Software, Inc. http://www.partnersoft.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]