Draws the bitmap into the active graphics device at its source
pixel resolution. Internally the bitmap is converted to a 3-D
numeric array (the format png::writePNG() and the R graphics
engine both consume cleanly) and drawn with grid::grid.raster()
on a fresh grid page.
Usage
# S3 method for class 'pdfium_bitmap'
plot(x, interpolate = TRUE, ...)Arguments
- x
A
pdfium_bitmapfrompdf_render_page()orpdf_image_bitmap()/pdf_image_rendered().- interpolate
Passed through to
grid::grid.raster(). DefaultTRUE; setFALSEfor pixel-exact (nearest-neighbour) display of small bitmaps.- ...
Further arguments passed to
grid::grid.raster().
Details
We go through as.array(x) rather than handing the integer matrix
directly to graphics::rasterImage() for two reasons that
compound:
Per the documented raster contract (see
?grDevices::as.raster, "Raster images are internally represented row-first"),"raster"andnativeRasterobjects must have row-major memory layout. R'sas.raster.matrix()transposes its input precisely to satisfy that. Our integer matrix comes out of C++ as a standard R column-major matrix, so feeding it directly is non-conformant and shows diagonal stripe artifacts on detailed content.rasterImagewithplot.windowuses the user-coordinate system, which defaults (xaxs = "r", yaxs = "r") to padding the interval by 4% on each side — silently compressing the raster into ~92% of the device and forcing sub-pixel resampling.grid::grid.raster()uses npc coordinates and isn't subject to this.
Going through as.array(x) to a 3-D c(H, W, 4) numeric array
and rendering with grid::grid.raster() sidesteps both: the
array path uses positional channel storage (no row-vs-column
convention), and grid coordinates are 0..1 npc without padding.
Examples
fixture <- system.file("extdata", "fixtures", "shapes.pdf",
package = "pdfium"
)
if (nzchar(fixture) && interactive()) {
bmp <- pdf_render_page(pdf_doc_open(fixture), dpi = 96)
plot(bmp)
}