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
