ArrayIndexOutOfBounds exception at line 761 of TIFFFaxDecoder.java

Submitted by wataylor on Mon, 04/04/2011 - 23:27

I have a .tif file DOLA13196.tif which is processed successfully if the “direct” parameter of TiffImage.getTiffImage is set true but causes an array index out of bounds exception if this parameter is set false.

The Javadoc says:

* @param direct for single strip, CCITT images, generate the image
* by direct byte copying. It's faster but may not work
* every time

Our application sets “direct” to false because of this comment. That works most of the time, but this particular .tif file fails unless “direct” is set to true. The Javadoc suggests that this should not be the case.

I am using iText 5.0.5.jar; our OS and Java version are:

C:>java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)

Per your instructions on the download page, we are using bcmail-jdk16-145.jar, bcprov-jdk16-145.jar, and bctsp-jdk16-145.jar.

I have a short test program BareBonesiText.java but I don't see a way to attach files to a forum topic.

For each .tif file listed on the command line, it attempts to create two .pdf files, one named “direct.pdf” and another named “indirect.pdf”.

With the out of the box iText code, the attempt with “direct” set to false fails at line 761 of TIFFFaxDecoder.java. However, if I add the statement:

if (changingElemSize < currChangingElems.length)

on line 760, the direct .pdf is generated successfully.

Our systems people are not enthusiastic about our modifying your code without your advice. Could you please let us know what’s the best thing to do?

Thank you very much. I can send the files by email if someone wants them. I asked this question of the sourceforge mailing list but it was ignored.

Bill Taylor

Does the problem persist in version 5.0.6?

Submitted by Bruno Lowagie on Tue, 04/05/2011 - 08:44.

A similar problem was reported and fixed in 5.0.6: http://1t3xt.be/?02c
"TiffImage: images with 1 bit per pixel may also use a pallete."
What happens if you switch to iText 5.0.6?

Note that TIFF is a tricky format. It's supposed to be "a" standard, but in reality, plenty of tools producing TIFFs use their own interpretation of "one of the TIFF standards". iText catches many of the errors in TIFFs, but not all. It's like "mopping up water with the faucet still on". Instead of "mopping up the water" (changing iText to deal with the errors), you should "turn the faucet off" (stop using faulty TIFFs).

I suggest that you first try iText 5.0.6. If that doesn't solve the problem, please try positing your question on the mailing list once more.