xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Welch <ar...@EASTPOINT.COM>
Subject RE: FOP and PDF Size
Date Thu, 14 Dec 2000 00:08:21 GMT
Just two more cents...

I could even see a situation where different settings may be required for
two different runs. consider a servlet environment where FOP is used to
create PDFs. Some PDFs may be created on-the-fly and should be configured
for an optimal compromise between speed and size. However there may be other
PDFs which are also created dynamically, but perhaps are of very large size
(or something) and are created and stored. For these the desired setting may
be absolute maximum compression with little regard to the compression time.

I just mention this so that whomever is thinking about FOP configuration
would keep this kind of runtime configuration issue in mind.

Art (no more sense/cents... tonight)

-----Original Message-----
From: Kelly Campbell [mailto:camk@channelpoint.com]
Sent: Wednesday, December 13, 2000 6:34 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


We need to figure out how we're supplying configuration for FOP so stuff
like this can be configured. I didn't notice that much of a difference in
time, but I also didn't test specifically for how much time it took. 

I'd say that on large documents like the one I was testing with (~50 pages,
several graphics) the time spent on compression is well worth it in this
case unless your clients have some T3 links. A 700k document would take more
than 2 minutes to download for a 56k modem. 300K would be about 60 seconds
by my calculations.

The Deflater in JDK allows for some options which I didn't use such as
BEST_SPEED or BEST_COMPRESSION. On images, using something like the PNG
filter and then the FILTERED option to Deflater can cut the size even more
if I understand the PNG spec right.

Once we get some story for configuring FOP more at runtime these types of
options can be explored more. Personally, I like the properties file
approach, but allowing for an additional set of super-ceding properties to
be passed in at runtime for stuff like Cocoon or other programatic users of
FOP. I added the flag in the file simply to give FOP developers an easy
place to switch it off for debugging output problems.

-Kelly

-----Original Message-----
From: Art Welch [mailto:art_w@EASTPOINT.COM]
Sent: Wednesday, December 13, 2000 3:53 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


How does compression affect performance? If it takes longer to compress the
data than would be offset by reduced transmission time, could this be made
configurable somehow? I did not see getter/setter methods in the patch and
the flag is private. Of course getting to the PDFStream may be a little
difficult anyway...

Art (down $0.02 more)

P.S. I think that this is real cool... now if we could get 6x compression...
in real-time...
I am concerned about this because our application creates PDFs on-the-fly
and eventually will be serving them out over the Net. So we need FOP to be
fast (or not too slow) and would also like smaller downloads (so they are
not too time consuming).

-----Original Message-----
From: Kelly Campbell [mailto:camk@channelpoint.com]
Sent: Wednesday, December 13, 2000 5:16 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


Attached is a patch for PDFStream.java which implements stream compression.
This produces similar results in size to the PJ post-processing method.

-Kelly

-----Original Message-----
From: Kelly Campbell [mailto:camk@channelpoint.com]
Sent: Wednesday, December 13, 2000 2:45 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


Actually I wasn't planning on using any of the PJ source for just that
reason. I was planning to just use the java.util.zip Deflater features.
JDK1.1 included support for this as well, so it shouldn't create any
problems there. The PDFStream source in FOP is very simple, and this would
complicate it a little bit, but I think that's probably ok.

I don't have Adobe's PDF products, so I can't investigate that, but I'd be
very interested to hear any findings from that. 

-Kelly

-----Original Message-----
From: Art Welch [mailto:art_w@EASTPOINT.COM]
Sent: Wednesday, December 13, 2000 2:11 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


Caution: I think that PJ suffers from GPL. On their site I found the
following statement:

"Can I redistribute PJ as part of proprietary or non-GPL software? 

No, PJ may be redistributed with GPL software only. Contact us for a
commercial redistribution license."

If the PJ compression just does ~2x, would it make more sense to investigate
the possibility of doing whatever PDFWriter does to achieve ~6x.

Art (my $0.02)


-----Original Message-----
From: Kelly Campbell [mailto:camk@channelpoint.com]
Sent: Wednesday, December 13, 2000 3:55 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


I just tried this... and it seems to work great. A 760K PDF from FOP
compressed into 320K. I'll look at adding a setting to FOP's PDF rendering
classes to flate-compress streams.

Attached is the modified source and compiled class I used with pj-1.10.jar.

-Kelly

-----Original Message-----
From: Kelly Campbell [mailto:camk@channelpoint.com]
Sent: Wednesday, December 13, 2000 1:46 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


You could also use Etymon's PJ library to postprocess the PDF and
flate-compress any stream objects.

http://www.etymon.com/pj/index.html

Look at the file in the pj.jar called
com/etymon/pj/samples/UncompressPdf.java
You can probably modify that to call PJStream.flateCompress() instead of
flateDecompress(). I'm not sure how much this will compress the file, but
it's worth a try.

-Kelly

-----Original Message-----
From: Joachim Diepstraten / media access
[mailto:Joachim.Diepstraten@media-access.net]
Sent: Wednesday, December 13, 2000 1:19 PM
To: 'fop-dev@xml.apache.org'
Subject: RE: FOP and PDF Size


Hi

>Can I do anything to optimize my input, or is it just the way FOP works?
Yep that's the way fop works. It doesn't use optimized bytestreams to encode
the
text things. If you open your PDF with Adobe's Acrobatwriter and save it
with optimize
option it's about factor 6-7 smaller but it's no longer easy to read in a 
text-editor

EOF,
  J.D.

Mime
View raw message