The way psfmtdrv+distiller and divpdf handle the bounding box values of an image is different.
- divpdf is more literal and is doing precisely what the values in the image are dictating.
- PDFlib does not handle EPS images natively; EPS images are converted to a PDF image for PDFlib.
- When EPS images are converted to a PDF for PDFlib, XPP must honor the BoundingBox (or cropping) information in an EPS image when the PDF image is created.
- That means that with divpdf, all EPS images will be cropped according to the BoundingBox information in the EPS image.
- psfmtdrv never applied the BoundingBox (cropping) values specified inside an EPS image to actually crop the image but rather used them to calculate the size of the image.
- If the uncropped image was bigger than the calculated size, the image was placed on the page according to its size but the image was not cropped to that calculated size.
To eliminate the image shift when using divpdf, the source image's BoundingBox values must be adjusted to the desired positioning.
Note that with psfmtdrv there is no "conversion" of the EPS image so no conversion is required.
For example:
- If the BoundingBox (or cropping) information for the image is (x1, y1, x2, y2) %%BoundingBox: 54 86 558 706
- Notice that there is a significant non-zero value for the x1 and y1 BoundingBox values (if the value is smaller there may not be a visible shift of the image with divpdf output)
- The calculated size of this image is x:558-54 (x2-x1)=504q and y:706-86 (y2 - y1)=620q; 504q is about 7in and 620q is about 8.6in.
- Look at the x2 and y2 (uncropped) values, 558q is about 7.7in and 706q is about 9.8in.
- Psfmtdrv does not crop the EPS image, so you get the full 7.7 x 9.8in image.
- Divpdf does crop the EPS image, so you get only the cropped 7 x 8.6in image.
If the full 7.7 x 9.8in image is desired (with divpdf), it's necessary for the BoundingBox values within the EPS image to be correct.