Hi @kimyu92,

Unfortunately PDFs put a lot of document information at the end of the file, so you usually need to scan the whole thing before starting. As soon as you call poppler_document_new_from_stream(), the first thing it does is read the whole file.

Perhaps pdfium is less greedy? I've not tested it for this.

libvips will render a page at a time, so the actual rendering process shouldn't need that much memory.

Also, it seems weird that we have to initialize the object again to get to a particular page.

This is a consequence of the way that libvips handles multipage images -- it represents them as a single very tall, thin image, with the pages joined together vertically (a "toilet-roll" image, sorry). If your PDF has pages that are all the same size (for example, it has no pages in landscape), then you can load the whole PDF in one go and loop over pages without reinitialisation.

Sadly many PDFs are not like this, so to work for all PDFs, where each page can be a different size, you need to reinitialise.

With a PDF where all pages are the same size you can do:

$ irb 
irb(main):001:0> require 'vips'
=> true
irb(main):002:0> x = Vips::Image.new_from_file "nipguide.pdf", n: -1
=> #<Image 595x48836 uchar, 4 bands, srgb>
irb(main):003:0> x.get "page-height"
=> 842
irb(main):004:0> 

Then you can use crop to pull out pages and libvips will render them to bitmaps on demand.

pyvips has pagesplit() and pagejoin() convenience methods to turn these tall, thin images into arrays of page images. We should probably add them to ruby-vips as well.