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!
Can we help you to solve any of these problems?
IDRsolutions has been helping companies to solve these problems since 1999.
|Convert PDF to HTML5 or SVG||Convert PDF forms to HTML5|
|Java SDK for Image files||Java SDK for PDF files|