Keiron Liddle ([EMAIL PROTECTED]) wrote To FOP on Tue, May 21, 2002 at 11:47:19AM +0200:
> I don't think we can apply this patch directly for a number of reasons. > Although there are parts in it with value that should be put into cvs > when you have finished. I figured as much. Mainly I wanted to get an example out for anyone to look at; the code I wrote is hardly high quality and I would rather do a more careful modification against CVS. Sorry about the formatting changes - emacs redid the indentation according to my weird standard and I was just too lazy to fix it back. Is there an apache or fop standard style or style canonicalizer? I know some projects use a tool to fix style to a standard. > Using temp files can cause problems in certain situations. Agreed. Here are some possible solutions: 1) a boolean switch (in the api or system properties) 2) intelligence in the buffer itself, where it uses a tempfile after a certain size is reached 3) better overall architecture where buffers are immediately flushed to output rather than remaining in memory (3) seems best and is in line with the next-gen design documents I see on the fop site, but I don't know how far along y'all are with that. I have to use a similar architecture for my map translation software; GIS systems are hundreds of megabytes and scalability requires a flat memory usage model. All my buffers are strictly memory-limited. (1) is easy enough (2) would be fine but probably has pitfalls; the problem is that there are a _lot_ of these buffers and PDFStreams running around, and therefore it's a global problem - I counted dozens for one plot, 24MB total. I was planning on using a switch for the cvs patch, unless y'all have (3) figured out. > I don't see the need for an extra PDFStreamGraphics2D class. Modifying > the PDFGraphics2D should suffice. Agreed. I just didn't want to break the existing (the current patch uses PDFStreamGraphics2D just for my case). > An extension may work better in this situation with the development > code. If I understand the problem properly. ?? An extension to the code, or a file extension for the URL? I'm not sure what you mean. As far as my plans for the other features: I figure the drawImage hack is a no-brainer. It's just the right thing to do in that instance. The additional memory usage should be no big deal (it's a hash of image pointer to integer ID). I'll just modify PDFGraphics2D directly to use the underlying PDFStream. I think this is fine for all cases. Should I break it up into several patches? -> tempfile buffering -> drawImage hack -> PDFGraphics2D hack -> on-the-fly images -- 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]
