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 Fri, 15 Dec 2000 19:02:32 GMT
Did I read that correctly. You changed Driver to use an OutputStream instead
of a Writer...

AWESOME!!! YIPPIE!!! HOORAY!!! YAHOO!!! FINALLY!!!

Hmmm (regains composure)

Why thank you kind sir. I have been hoping that someone would do this. Even
suggested it a couple of times. I am sure that other people using non-plain
text renderers will appreciate this as well.

Thank You,
Art (java.io.Writer hater!)

-----Original Message-----
From: Kelly Campbell [mailto:camk@camk.net]
Sent: Friday, December 15, 2000 4:45 AM
To: fop-dev@xml.apache.org
Subject: Re: FOP and PDF Size


I think I've tackled most of the big issues related to this, and have it 
working now. This did require a change in many of the interfaces 
concerning rendering, and even Driver because we need to pass 
OutputStreams around rather than PrintWriters, so this is a major change 
since Driver has to change. I couldn't think of any ways to make driver's 
setWriter call work since there's no way to get a the underlying stream 
for a writer. :-(

I also redesigned PDFFilter to be an interface which individual 
implementations simply need to implement to provide filters other than 
FlateDecode. This greatly simplified the code, and allowed me to removed 
PDFBinaryStream completely. So when working with a PDFStream, you can do 
something like the following:

PDFStream obj = new PDFStream(x); // x = object id
obj.addFilter(new FlateFilter());
obj.addFilter(new MyOtherFilter()); // filters are run in order they are 
                                    // added

I'm attaching a big patch and a new file for people to take a look at and 
see if they agree to the changes since the interfaces to other external 
systems that user Driver will break. 

Also, some notes on performance. I could not determine any discernable 
differences in time between a non-compressed build of 
docs/examples/runtests and a compressed version. In both cases, almost 
every run of that task takes around 30 seconds on my system. Readme.pdf 
went from 120K uncompressed to 35K compressed.

-Kelly


On Fri, Dec 15, 2000 at 10:13:04AM +0100, Eric SCHAEFFER wrote:
> It would be great if you could help me changing and using these classes (I
> did it some time ago, but just with image compression in mind).
> 
> Eric.
> 
> Cordialement,
> Eric SCHAEFFER
> 
> Consultant TechMetrix Research
> http://www.techmetrix.net
> Groupe SQLi
> http://www.sqli.com
> Créateurs de sites intelligents depuis 1995
> 
> FOP, the first XSL:FO processor
> http://xml.apache.org/fop/ 
> 
> > -----Message d'origine-----
> > De: Kelly Campbell [mailto:camk@channelpoint.com]
> > Date: jeudi 14 décembre 2000 16:32
> > À: 'fop-dev@xml.apache.org'
> > Objet: 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, which
> > 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 be
> > 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 away
> > 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 where
> > compression begins to win)
> > 
> > -Kelly
> > 
> > -----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 (need
> > surelly some changes). We should try to use it to compress 
> > the entire PDF...
> > 
> > And if you have some ideas on how to modify these classes 
> > (interfaces),
> > you're wellcomed ;)
> > 
> > Eric.
> > 
> > 
> > Eric SCHAEFFER
> > Consultant TechMetrix Research
> > http://www.techmetrix.net
> > Groupe SQLi
> > http://www.sqli.com
> > 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.
> > > 
> > 

-- 
Kelly A. Campbell                        Software Engineer
camk@channelpoint.com                    Channelpoint, Inc.
camk@camk.net  camk@merlotxml.org        Colorado Springs, Co.

Mime
View raw message