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?
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 13 years worth of PDF knowledge and tips, so click here to visit our series index!
IDRsolutions develop a Java PDF library, a PDF forms to HTML5 converter, a PDF to HTML5 or SVG converter and a Java Image Library that doubles as an ImageIO replacement. On the blog our team post about anything interesting they learn about.
