xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelly Campbell <c...@channelpoint.com>
Subject RE: FOP and PDF Size
Date Thu, 14 Dec 2000 18:31:16 GMT
 Don't use this patch yet. I just found out from a colleague that it creates
unreadable PDF files for Windows users when I generate a file on linux.
Linux's acroread can read the files just fine, so it's probably something
with the character encoding of the compressed stream. I'm probably going to
have to change the PDF Object classes to render to byte arrays rather than
Strings as noted to fix this.


-----Original Message-----
From: Scott Jones
To: fop-dev@xml.apache.org
Sent: 12/14/00 10:21 AM
Subject: Re: FOP and PDF Size

First off, I just want to say that this compression addition is
I can't wait to check it out, because it is going to be very valuable
me.  :)

The tradeoff point for the compression when you are using Cocoon totally
depends on the target file transfer rate to your users (and how
your bandwidth is).  I think that in some cases, such as mine, we are
talking about 56k modems.

My largest PDF file is 250kB, uncompressed.  So, on a 56K modem, I
that would take around 45 seconds.  So, cutting the file size in half
make a huge difference in my performance for modem users (even if my
takes a little longer to generate the pdf...).  My average file size is
pretty small -- probably somewhere around 60kB right now (still around
seconds on a modem)...

If your target audience is still stuck on modems, then I'm not sure that
there is a tradeoff point.  By the time that the file sizes get small
that the transfer times are comparable to the processing time, the file
pretty simple, and probably wouldn't be too hard to compress (?)

If your users are on T1 lines, then you are talking about a different
and 100kB is probably a good estimate for the tradeoff point.  However,
bandwidth is a concern, then that throws in another variable...

I'd say that compression should be on by default.


----- Original Message -----
From: "Kelly Campbell" <camk@channelpoint.com>
To: <fop-dev@xml.apache.org>
Sent: Thursday, December 14, 2000 7:32 AM
Subject: RE: FOP and PDF Size

Yup, I missed that. Thanks. It shows me that I need to sit down and read
through more of the code.

It's in BinaryStream. All text goes through the normal Stream object,
is why I added it there. I'll look at integrating the two and possibly
changing the interface be byte array based. I think that will probably
helpful down the road if people want to use FOP with non-latin character
encodings too.

On the configuration, I didn't notice the config for hyphenation right
either. It should work fine for these compression properties. What size
documents are people typically rendering in Cocoon? I can see how
compression would be a problem if the document is rather small because
compression could essentially double the amount of time it takes to
render a
small document (around 100K is my guestimate for the tradeoff point
compression begins to win)


-----Original Message-----
From: Eric SCHAEFFER [mailto:ESCHAEFFER@Techmetrix.net]
Sent: Thursday, December 14, 2000 3:26 AM
To: fop-dev@xml.apache.org
Subject: RE: FOP and PDF Size

Hey, there's some classes to handle compression in the PDF part of FOP
surelly some changes). We should try to use it to compress the entire

And if you have some ideas on how to modify these classes (interfaces),
you're wellcomed ;)


Consultant TechMetrix Research
Groupe SQLi
Créateurs de sites intelligents depuis 1995

> -----Message d'origine-----
> De: Art Welch [mailto:art_w@EASTPOINT.COM]
> Date: mercredi 13 décembre 2000 22:11
> À: 'fop-dev@xml.apache.org'
> Objet: 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.

View raw message