Re: direct rendering of images to pdf

2002-05-15 Thread Paul Reavis 

Success!! I've gotten vector map plots at E-size and bigger, with
multiple plots per PDF even. I had to chase down quite a few issues,
and made a real mess of the code base, so will have to go back and
clean up some things. Basically, though, the three major bottlenecks
were:

1) creation of pdf image objects every time drawImage was called - I
put in a cache that detected when the same image was used more than
once

2) direct streaming to the pdfstream by PDFGraphics2D

3) storage of the bytes in a PDFStream in a tempfile rather than a
byte array - I had about 24MB of temp files. This necessitated
rewriting the filters to work on streams instead of byte arrays, but
that ended up being straightforward

It's far far far faster than the SVG solution. On a 1GHz machine we
were plotting multiple E size plots into a PDF in about 12 seconds. 

Here is an example - the state of new hampshire at 44in x 68in. It's
about 3MB. 
http://www.partnersoft.com/news/images/NewHampshire-Full.pdf

What is the position on tempfile use? I forget which JDK version added
them... I could probably make it semi-intelligent, where a buffer reverts to
a tempfile when it gets big enough. But that adds complexity of
course.

-- 

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]

RE: direct rendering of images to pdf

2002-05-14 Thread Jim Urban 

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]