Yes the several patches is good, thanks. This way the appropriate ones can be applied to both code bases.
I agree that 3 is probably better and should be done for the development code. 1 is suitable for a quick solution for the maintenance branch. As for the extension, this is really for the development code. I don't know exactly where you are getting your data etc. from but the new code could handle this as an extension. The svg drawing itself is an extension and it could be done in the same way. You supply a handler on the user agent, this handler receives some xml data and has access to the pdf document, streams etc. This could make it easier but I would need more info. On Tue, 2002-05-21 at 16:00, Paul Reavis wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
