All images have a name in the PDF image XObject, usually along the lines of IM0, IM1, IM2, etc. This is unique for each page, so there will be only one Im0 on each page.
If the PDF page contains XForm objects, they can also contain images. These need to be unique for the XForm, but can be the same as a value used on a page. Similarly, the XForm can contain XForms with their own images, and so forth. So you could have this situation.
Main page with images Im0, Im1, Im2, Im3 and XForm XF1. This could have images Imo, Im1, Im2 another XForm with yet more images.
I was recently caught out by this because I was using the image name (Im0) as a key (I should have been using something like Im0, XF1.Im0 and XF1.XF1.Im0 to provide unique keys.
The name is used to reference to Images in the Resources object. In this case, each XForm has its own unique resources object (or uses the global resources), so Im0 works correctly in this context.
So you need to be careful with names in PDF files. You have a similar issue with Forms name, where sometimes you use just the Form name and any inherited values from its parent. But that is for another article…
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)
- How we are improving our code quality with IDEA in 2018 - March 7, 2018
- How we are improving our code quality with NetBeans in 2018 - March 1, 2018
- 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