xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric SCHAEFFER <ESCHAEF...@Techmetrix.net>
Subject RE: external-graphic, tif images, jimi, and *Reader.java
Date Mon, 18 Dec 2000 09:28:26 GMT
I want to re-write the image package: 
- to use Java native "classes" to use/modify image data
- to be able to insert image data unchanged if the output format can handle
it (PDF can use JPEG, TIFF as you said, etc...)

But keep in mind that PDF in't the only output format.

But that's a hard work, and I don't have time.
I'd like to post a proposal in a few days. Just tell me what you think about
it then ;)

Eric.

PS: the CVS have a JAI image class too.

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: Neal C. Evans [mailto:nce@uab.edu]
> Date: vendredi 15 décembre 2000 22:06
> À: fop-dev@xml.apache.org
> Objet: RE: external-graphic, tif images, jimi, and *Reader.java
> 
> 
> I was able to use your tiff reader to successfully read in 
> tif file into a
> pdf (woohoo! thanks), but I have discovered a few other issues.
> 
> 1.  The cool thing about tiffs, according to our graphics 
> person, is that
> they use an extremely efficient compression algorithm, and 
> can represent a
> ton of data in very small files.  Now, in looking at 
> JimiImage.loadImage()
> it looks like the image data is being _uncompressed_ and placed into
> this.m_bitmaps.  On very large tiff files, say with a width 
> of 2320 and a
> height of 3408, this results in an array size of 2320 x 3408 
> x 3 = 23719680!
> Obviously, most jvms will barf on the 'this.m_bitmaps = new
> byte[this.m_bitmapsSize];' line, when this.m_bitmapsSize is 
> such a large
> number.
> 
> 2.  Which leads to the question, why do you uncompress the 
> image before
> placing it into the pdf?  In the above example, the 2320 x 
> 3408 image is
> represented by a tiff that has a filesize of ~40 kb.  It seems like
> FopImage.getBitmaps() could be modified so that it returns a 
> byte[] array of
> the actual compressed data.  I also noticed in 
> PDFXObject.output() (once
> place where FopImage.getBitmaps() is called) that there are a few
> interesting lines:
> 
> 		imgStream.setData(fopimage.getBitmaps());
> 		imgStream.encode(new PDFFilter(PDFFilter.FLATE_DECODE));
> 		imgStream.encode(new 
> PDFFilter(PDFFilter.ASCII_HEX_DECODE));
> 
> In PDFFilter.java, the following is also defined:
> 
> 	public static int CCITT_FAX_DECODE = 5;
> 
> I happen to know the tiffs are encoded with the CCITT 
> algorithm, so, if
> 'PDFFilter.FLATE_DECODE' were replaced with 
> 'PDFFilter.CCITT_FAX_DECODE' and
> fopimage.getBitmaps() returned an byte[] array of the 
> compressed tif would a
> valid pdf result?
> 
> Why not use compression for all image types?  Wouldn't this 
> mean smaller
> pdfs?
> 
> Thanks for your help,
> 
> Neal
> 
> 
> Neal Evans, Ph.D.
> Senior Applications Architect
> Knowledge Management Objects, LLC
> (703) 841-4287
> 
> > -----Original Message-----
> > From: michaell@lilith2.dpo.uab.edu
> > [mailto:michaell@lilith2.dpo.uab.edu]On Behalf Of Michael Lee
> > Sent: Friday, December 15, 2000 11:40 AM
> > To: fop-dev@xml.apache.org
> > Subject: Re: external-graphic, tif images, jimi, and *Reader.java
> >
> >
> > I wrote an analyzer to recognize TIFFs.  Here it is again.
> >
> > Have fun!
> >
> > -Michael
> >
> > Eric SCHAEFFER wrote:
> > >
> > > The analyser sub package is here only to read the image 
> size (in pixels)
> > > without loading the entire image data.
> > > It also checks the image type.
> > >
> > > If you know how to read these informations from tif images, you
> > can write an
> > > analyser for this image type.
> > > But I'd like to change the FopImageFactory to use analysers if
> > it exists one
> > > that match, and try to load the image data (using image
> > classes) if there's
> > > no analyser.
> > >
> > > Simple configuration has just been added to the CVS source,
> > I'll modify the
> > > FopImageFactory to use it.
> > >
> > > Eric.
> > >
> > > PS: the CVS source has a JAI implementation, if you prefer...
> > (Jimi is not
> > > supported any more by SUN)
> > >
> > > 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: Neal C. Evans [mailto:nce@uab.edu]
> > > > Date: jeudi 14 décembre 2000 22:45
> > > > À: fop-dev@xml.apache.org
> > > > Objet: fo:external-graphic, tif images, jimi, and *Reader.java
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > We are trying to use the fo:external-graphic tag to import
> > > > tif images into
> > > > pdf documents we are generating via fop-0.15.  This doesn't
> > > > work, and we get
> > > > the following error:
> > > >
> > > > Error while creating area : No ImageReader for this 
> type of image
> > > > (file:../graphics/test.tif)
> > > >
> > > > Other formats, gif, jpg, png and bmp, all work just fine, as
> > > > I'm sure you're
> > > > all aware.  I was a bit surprised that tif support doesn't
> > > > come by compilign
> > > > fop with jimi, since jimi certainly understands tifs.
> > > > Looking through the
> > > > code, it looks like no TifReader.java has been created in
> > > > src\org\apache\fop\image\analyser.  Has anyone done 
> this already?
> > > >
> > > > If not, how do I go about creating this myself?  Can someone
> > > > (perhaps the
> > > > author of the other *Reader.javas) explain to me how to go
> > > > about properly
> > > > setting up the setDimension() and setDefaultHeader() 
> methods for a tif
> > > > format file?  Looks like I will have to make some fairly
> > > > academic changes to
> > > > ImageReaderFactory.java and FopImageFactory.java as well.
> > > >
> > > > Thanks for your help,
> > > >
> > > > Neal
> > > >
> > > > p.s. I realize we could just convert the tifs to other
> > > > formats.  There are
> > > > other problems that I need not discuss here that force 
> us to use tif.
> > > >
> > > >
> > > > Neal Evans, Ph.D.
> > > > Senior Applications Architect
> > > > Knowledge Management Objects, LLC
> > > > (703) 841-4287
> > > >
> 

Mime
View raw message