On Sun, 14 Aug 2005 09:14 pm, Jeremias Maerki wrote:
> 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-m
>aintain/src/org/apache/fop/pdf/CCFFilter.java
>
Adding CCFFilter from 0.20.5 is the easy bit and I have done that.
Unfortunately the JPEG handling model is not quite suitable for TIFF and 
that's where I am stuck. For JPEG a PDF document can include the whole 
file as part of the DCTFilter. This is not true for TIFF. Only certain 
TIFF formats are supported by the CCFFilter and only the actual image 
data from the TIFF file goes into the filter. All the meta information, 
e.g. the TIFF directory, is not stored in the PDF file. Therefore I 
cannot really use the FopImage.loadOriginalData() function because it 
would load the full data. Of course I could give that function a 
different meaning in the TIFF context but that may stuff up other 
render implementations in the future which assume that this function 
returns all the data but may be thats not such a big deal. In addition 
TIFF is currently supported through BatikImage. I don't think once 
Batik has the inputstream decoded, e.g. read the TIFF directory, I have 
access to the raw data required for the CCFFilter.

So I suggest the following. We provide two TIFF image implementations. 
One based on JAI as in 0.20.5 which allows native embedding in a PDF 
using the CCFFilter and one through Batik. If JAI is available the JAI 
TIFF implementation is chosen and smaller PDFs are produced in other 
environments the Batik variant is used.

Does that sound OK?

Manuel

<snip>
> > > 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

Reply via email to