The amount of data is given by the Width and Height keys. This image is 594
samples wide and 544 samples high. Notice that no resolution is given, the
effective resolution of the image is given by seeing how large the area
To start with in PostScript and PDF the image is assumed to cover the unit
square, and then the current transformation matrix is applied to scale it
into the desired output.
In your case this is given as :
142.5 0 0 130.5 0 2.072713 cm
So your image is scaled anamorphically, by a factor of 142.5 in the x
direction and 130.5 in the y direction. So your image now covers 142.5
units by 130.5 units. PDF units (like PostScript) are 72 to the inch, so
your image covers 1.98 inches by 1.81 inches (looks about right by visual
I used the Acrobat Pro 9 measurement tools to verify this (screenshot
You image is therefore 594/1.98 = 300 dpi by 544/1.81 = 300.55 dpi.
Confirming your resolution.
Looking at output-few.pdf we see that the pdfwrite output is a little more
complex, and involves concatenated CTM operations. However, the image is
still defined as:
Because you have specified a resolution of 300 instead of the default 720
the numbers are a little different in the content stream:
q 0.24 0 0 0.24 0 0 cm
q 593.75 0 0 543.75 122.277 2608.77 cm
We concatenate the matrix operations as before, yielding a CTM of
593 x 0.24 = 142.5
543.75 x 0.24 = 130.5
122.27 x 0.24 = 29.3448
2608.77 x 0.24 = 626.1048
The important values, the x and y scale are the same as the previous 2
cases, and therefore the image has the same resolution, 300 dpi.
Now, your PDF Checkpoint tool is out by a factor of 10 in the case of
output-few.pdf, which is exactly the scale factor applied by the initial
'cm' operation. In the case of output-many.pdf it is out by a factor of
4.166 which is exactly the same as the scale factor in the initial 'cm'
operation in that file (0.24).
It seems clear to me that the application is *not* properly interpreting
the PDF file, it looks like it is assuming that each 'cm' operation is
atomic rather than cumulative and only seems to be tracking the last such
operation. As a result it is applying only that matrix to the image to
determine its resolution. It should be applying the combined effect of the
> Of course, this could be a bug in PDF Checkpoint but
>since we couldn't find many other checkers, we decided to be cautious. If
>this checker gets it wrong (while getting others right), then perhaps other
>apps in a printer's workflow will be confused too.
The only app you should need to worry about is a PDF interpreter, since it
will be guided by what's in the PDF file, it won't get confused. If it
does, then its a bug in the application and you should report it to the
authors. There isn't anything we can do about other people's bugs.