Oh, right, looks like the CCFFilter needs to be ported from the maintenance branch to the trunk. I didn't remember that one. The Batik codecs are actually not so much involved in this case, since the TIFF doesn't have to be fully decoded. Have a look at how JPEG is handled. The JPEGs are simply analyzed by the JPEGReader and the directly provided as a byte stream (undecoded) in JPEGImage to the renderers.
http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/pdf/CCFFilter.java On 13.08.2005 07:46:49 Manuel Mall wrote: > On Fri, 12 Aug 2005 06:48 pm, Jeremias Maerki wrote: > > On 12.08.2005 12:00:05 Thomas DeWeese wrote: > > > Jeremias Maerki wrote: > > > > Ideally, the *Reader implementations (analyser package) for each > > > > format should actually read the extents and the bitmap resolution > > > > already. It should not be deferred to the actual codec, if > > > > possible. That makes it possible to work with the image (during > > > > layout) without fully loading it already. > > > > > > Well IMO the right thing is for the image codec to defer the > > > loading of the image data until requested. This way you only need > > > one set of parsing code to get right and maintain. It can also > > > simply the coding as you don't have to switch between multiple > > > representations. > > > > > > This is the way the imageio classes work. Also some of the > > > Batik codec's work this way (Tiff). > > > > Of course, but we have to deal with a mix of different image sources > > here which don't all support that kind of stuff. That's why the > > analyser package exists. Also, it is necessary to support direct > > embedding of JPEG and EPS graphics into PDF and PS, for example. I > > hope I understood you right. > > > Actually 0.20.5 supports direct embedding of TIFF in PDF as well. This > is a very important feature for our application as we have lots of TIFF > images (actually incoming faxes) which we bundle into PDFs using FOP. > Would hate to see that getting lost in the trunk code. Not sure how > this could be done with the Batik stuff as the PDF renderer would need > access to the undecoded stream in that case. > > Manuel Jeremias Maerki
