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)
- 3 ways that the European Union is changing the way Companies write software in 2018 - January 31, 2018
- IDRsolutions product range update for 2018 - January 22, 2018
- 4 ways Companies can make remote working successful - December 21, 2017
- My experience of a Turkish bath (visiting Istanbul for DevFest) - November 24, 2017
- My 5 key takeaways from JavaOne 2017 - October 6, 2017