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!
Latest posts by Mark Stephens (see all)
- My experience of a Turkish bath (visiting Istanbul for DevFest) - November 24, 2017
- My 5 key takeaways from JavaOne 2017 - October 6, 2017
- My notes and pictures from thursday JavaOne 2017 - October 5, 2017
- My notes and pictures from Wednesday JavaOne 2017 - October 5, 2017
- My notes and pictures from Tuesday JavaOne 2017 - October 4, 2017