Now that we can draw in our PDF, we want to add images. There are two kinds of images, bitmapped and vector. In PDF, images are called XObjects (The X stands for external, meaning defined outside the page). Vector images are easier, since they are just packages of PDF drawing commands, a sort of macro. PDF calls them Forms, since they were originally used to draw the boxes on a printed form.

See the code.

Vector graphics

Using an XObject Form involves three parts:

Define the image
Create a content stream with the drawing commands, like:
6 0 obj
/Subtype /Form % defines the type of image
/Resources 2 0 R % just like the resource dictionary for a page; no reason not to use the same one
/BBox [0 0 40 40] % the bounding box of the image, as [left bottom right top]. No reason not to use [0 0 width height]
/Length 47
5 w
0 0 40 40 re % draw a black box
0 0 0 RG S
Define a name for the image
In the resource dictionary, determine a name for the image (this is arbitrary) in the /XObject subdictionary:
2 0 obj
  % ... other resource definitions
  /XObject << 
    /Image1 6 0 R % the name of object 6, defined above
    % ... other images
Use the image
In the content stream for the page, include the command
/Image1 Do

The question is obvious: how do you tell PDF where on the page to draw the image? The answer is, you don't. The drawing commands draw a box from (0,0) to (40,40), and that's where it's drawn. But you object: that makes them worthless!

The trick is to redefine the coordinate system so that (0,0) ends up where you want. PDF uses affine transformations:

x? = ax+cy+e
y? = bx+dy+f

where x is the x-coordinate in the new coordinate system (where the image "thinks" its drawing) and x? is the x-coordinate in the original coordinate system. So to put the image with the lower left corner (its (0,0) point) at (50,100), you would want to have x? = x+50 and y? = y+100, or a=1 b=0 c=0 d=1 e=50 f=100. The PDF command for that is cm (for coordinate matrix), so the drawing command would be:

1 0 0 1 50 100 cm
/Image1 Do

Coordinate transformations are cumulative, so repeating the translation for another image would push it too far. You want to reset the transformation matrix before each drawing. You could calculate the inverse matrix (for the translation above, it's easy: 1 0 0 1 -50 -100 cm, but other transformations are more complicated) but PDF has an easier way: a graphics state stack. q pushes the current graphics state, including the transformation matrix, and Q pops it, so the final drawing command would be:

1 0 0 1 50 100 cm
/Image1 Do

Other transformations are possible, and the work of getting the math right has already been done:

Translation of the origin to (x,y)
As above, 1 0 0 1 x y cm.
Rotation around the origin by angle theta
cos(theta) sin(theta) –sin(theta) cos(theta) 0 0 cm.
Scale (change the size of) the x-direction by a factor xscale and the y-direction by yscale
xscale 0 0 yscale 0 0 cm

These do the transformation around the origin (and doing them in the above order has the expected results; doing the transforms in some other order means translating in scaled units or along rotated axes, which is rarely what you want). More often, we want to place and rotate around the center of the image, so after the transformation, translate backwards half the height and width (in the new coordinate system): 1 0 0 1 -width/2 -height/2 cm.

Bitmapped graphics

Bitmapped images are simply streams of bits, with a given color space (grayscale, CMYK or RGB) and a given number of bits per color component (grayscale has one component, CMYK has four and RGB has three). The easiest to use is RGB, with 8 bits per component, since that translates directly from the PHP image routines.

Using a bitmapped image is exactly the same as for a vector image, except the content stream is different:

7 0 obj
/Subtype /Image % defines the type of image
/Width 50 % no bounding box, just a width and height
/Height 50
/ColorSpace /DeviceRGB
/BitsPerComponent 8
/Length 2500
...generate the bytes

And "generate the bytes" for a PHP image is straightforward:

for ($row = 0; $row < $height; ++$row) for ($col = 0; $col < $width; ++$col){
  $colorindex = imagecolorat($im, $col, $row);
  $colors = imagecolorsforindex($im, $colorindex);
  $image->contents .= sprintf('%c%c%c', $colors['red'], $colors['green'], $colors['blue']);

There is a huge gotcha here: the image is always scaled to be 1 pixel square. I don't know why; the width and height are there in the image definition, but that's the way it is. So you have to scale the image with width 0 0 height 0 0 cm (or multiply width and height by some scale factor) before displaying with /bitmappedImage1 Do. Then, since the units are now scaled, to place and rotate around the center you have to use 1 0 0 1 -0.5 -0.5 cm (half the original (1x1) sizes). Trust me, this works.

The final code is pretty simple.


See the example.

Create the apple vector image:

//, same as last example but now going into an Xform
$pdf->fill (0,149,182); // biondi blue
$pdf->appendForm('apple', 101, 121);

And if we have these images: smiley.png smileyand smiley2.png long smiley we can create bitmapped images:

$im = imagecreatefrompng('smiley.png');
$im2 = imagecreatefrompng('smiley2.png');

And use the images:

$pdf->placeimage('apple', 0, 0, 0, 1, 3); // centered at origin, stretched vertically
$pdf->placeimage('apple', 300, 300); // image placed straight
$pdf->placeimage('apple', 300, 500, M_PI/2); // rotated up 90 degrees
$pdf->placeimage($im, 200, 200); // image placed straight
$pdf->placeimage($im2, 200, 400, deg2rad(60)); // rotated 60 degrees


You will notice there is no mention of the alpha channel in the images or other forms of transparency. This is a format from 1993, after all. We were lucky to have transparent colors in our GIFs. But it is possible; see the transparency and alpha channel extensions to FPDF. I just am not going to go into it here.


The classes presented here allow for gzip compression, but there are better ways to compress images. PDF supports png and jpeg compressed images, as well as color palettes to reduce the bits per pixel. See the FPDF functions Image, _parsejpeg and _parsepng for details.


One Comment

  1. Hacking at 0300 : Changing Images in a PDF says:

    […] images are stored as individual objects in the PDF file, so if there is an image I can identify, I can easily replace it with one of my own choosing. The […]

Leave a Reply

Warning: Undefined variable $user_ID in /home/public/blog/wp-content/themes/evanescence/comments.php on line 75