diffs and new files for tempfile-based PDFStream support

[Paul Reavis <pr...@partnersoft.com>]

Here's the output from `cvs diff` as well as the new files (how do I
get a diff or patch equivalent for files that are new? I can't `cvs
add` since I don't have write access, and it ignores non-cvs files) 

This patch:
1) adds a new class, org.apache.fop.util.StreamUtilities, that
provides some buffered stream copying routines - InputStream to
OutputStream. Adapted from my own IOLib, nice and fast and clean. Used
by several of the new classes.

2) modifies the current behavior of PDFFilters to operate on streams
instead of byte arrays.

3) changes the type of the ByteArrayOutputStream _data field of PDFStream to a new
abstract class, StreamCache

4) Added two implementations of StreamCache, InMemoryStreamCache and
TempFileStreamCache. The InMemory behaves much like the current FOP
implementation, with a ByteArrayOutputStream. The TempFile
implementation uses temp files.

5) a static factory method, PDFStream.createStreamCache(), creates the
desired type. Another static method,
PDFStream.setCacheToFile(boolean), sets which to use. 

Other StreamCache implementations are certainly possible; perhaps a
smart one that only caches to file when a certain size is reached
(StreamUtilities.BUFFER_SIZE perhaps). The problem with such a
solution is death-of-a-thousand-paper-cuts - you may have quite a few
small StreamCaches that end up killing scalability anyway.

Note that I was not able to test these changes - the current
cvs fop does not run and says so plainly. Is there some way I can run some
basic sanity tests at least? I would like to do some memory audits (we
own a seat of OptimizeIt) but need to be able to run some real-life
examples.

Thanks...

-- 

Paul Reavis                                      preavis@partnersoft.com
Design Lead
Partner Software, Inc.                        http://www.partnersoft.com

Re: diffs and new files for tempfile-based PDFStream support

[Keiron Liddle <ke...@aftexsw.com>]

Hi Paul,

Thanks for the patch.
I have committed it.
For the testing, it works for a simple file. Eventually this sort of
testing could be done with the area tree xml -> pdf conversion but this
is not fully working right now.

Eventually we should try to use some common caching system that will
also handle other caching needs. Probably using some library.


The patch didn't quite compile properly. Sometimes you need to do a
build clean first to catch things.

On Thu, 2002-05-23 at 19:11, Paul Reavis wrote:
> Here's the output from `cvs diff` as well as the new files (how do I
> get a diff or patch equivalent for files that are new? I can't `cvs
> add` since I don't have write access, and it ignores non-cvs files) 
> 
> This patch:
> 1) adds a new class, org.apache.fop.util.StreamUtilities, that
> provides some buffered stream copying routines - InputStream to
> OutputStream. Adapted from my own IOLib, nice and fast and clean. Used
> by several of the new classes.
> 
> 2) modifies the current behavior of PDFFilters to operate on streams
> instead of byte arrays.
> 
> 3) changes the type of the ByteArrayOutputStream _data field of PDFStream to a new
> abstract class, StreamCache
> 
> 4) Added two implementations of StreamCache, InMemoryStreamCache and
> TempFileStreamCache. The InMemory behaves much like the current FOP
> implementation, with a ByteArrayOutputStream. The TempFile
> implementation uses temp files.
> 
> 5) a static factory method, PDFStream.createStreamCache(), creates the
> desired type. Another static method,
> PDFStream.setCacheToFile(boolean), sets which to use. 
> 
> Other StreamCache implementations are certainly possible; perhaps a
> smart one that only caches to file when a certain size is reached
> (StreamUtilities.BUFFER_SIZE perhaps). The problem with such a
> solution is death-of-a-thousand-paper-cuts - you may have quite a few
> small StreamCaches that end up killing scalability anyway.
> 
> Note that I was not able to test these changes - the current
> cvs fop does not run and says so plainly. Is there some way I can run some
> basic sanity tests at least? I would like to do some memory audits (we
> own a seat of OptimizeIt) but need to be able to run some real-life
> examples.
> 
> Thanks...



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org