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]

Reply via email to