The rectangular region is specified by the x,y coordinates of its upper-left corner and its width and height - in bitmap coordinates, not PDF coordinates. That is, if the whole-page bitmap would have been 1000 pixels wide and 2000 pixels high, and you request a region with (x,y) = (0,0) and (w,h) = (1000,500), the resulting bitmap will be the top fourth of the page.
In the Windows DLL version, this function fills in a
BITMAPINFOHEADER struct; in the Linux and Mac OS X
versions, it fills in a
On all platforms, the other arguments are:
page= page number
regionY= upper-left corner of region
regionH= width and height of region
dpi= resolution (dots per inch)
color= color setting - one of:
pdfImageMono: 1-bit monochrome
pdfImageGray: 8-bit grayscale
pdfImageRGB: 8-bit RGB
pdfImageDevNToRGB: 8-bit RGB, rasterized in DeviceN and then converted to RGB
pdfImageGrayToMono: 1-bit monochrome, rasterized in 8-bit grayscale and then converted to 1-bit
bits= pointer to the returned bitmap data
pdfImageDevNToRGBmode produces RGB output like
pdfImageRGB, but does the rasterization in DeviceN (CMYK + spot colors) so overprint previews will be more accurate.
pdfImageGrayToMono mode does the rasterization in
8-bit grayscale and converts to 1-bit monochrome at the end. This is
useful for files that use transparency – because 1-bit
monochrome mode doesn't support transparency.
On Windows, the data returned in
bits is stored in
bottom-up (upside-down) format, with each line padded to a multiple of
32 bits (standard Windows bitmap format).
On Linux and OS X, the data returned in
bits is stored in
top-down format, with no line padding. The
struct contains the following fields:
width= image width
height= image height
color= the color argument passed to
pdfOkif successful, otherwise an error code.
The caller is responsible for freeing the
after using it, by calling