CCITT encoding in PDF files - rows and height gotcha

While rewriting our CCITT decoder (almost finished!) we came across an interesting item to take care of. When reading the values of a CCITT encoded data stream, you need to be careful with the values you read in. In general, the CCITT dictionary can contain a /Rows value which is actually the height of the image data.

Have a look at this example from a PDF file created with OpenOffice.

 0 obj
BitsPerComponent 1
/ColorSpace/DeviceGray
/Filter[/CCITTFaxDecode]
/DecodeParms[<>]
/Length 8 0 R
>>

In this there is a /Rows value of zero (which is obviously impossible). So I double-checked the PDF File specification and a value of zero is allowed (in fact it is the default). But it is ignored and you use the height value instead. So why does OpenOffice write out a default value which is ignored (making the file larger)? And why does the PDF file specification allow a value it then ignores in the first place?

Would you like to know more about PDF files?

This post is part of our “Understanding the PDF File Format” series. In each article, we discuss a PDF feature, bug, gotcha or tip. If you wish to learn more about PDF, we have 20 years worth of PDF knowledge and tips, so click here to visit our series index!

Do you need to read or write Tiff files in Java?

Our JDeli image library offers a range of advantages over ImageIO and alternatives for Tiff files, including:

prevents heap related JVM crashes
reads 1-32 bit bilevel, grayscale, rgb, argb, cmyk, acmyk, ycbcr Colorspaces, and converts to sRGB BufferedImage
implements both Little and Big Endian Byte Ordering
decompresses uncompressed, CCITT group 3 and 4, Deflate/Adobe Deflate, LZW, Packbits
support for Single, Multi-file, Tiling, Planar (Chunky, Separated), Predictor, 16,32 bit floating samples
improve read performance
supports threading
superior image scaling algorithms

Learn more about JDeli, or download it to try it yourself.