2

I have to render a PDF into a very high resolution image (say up to and even over 100,000 * 80,000 pixels).

I managed to do that without going out of ram by splitting the render into several slices and then rendering each one using NSOperationQueue, basically drawing the NSImage pdf representation into a new NSImage using drawInRect:fromRect:operation:fraction: and then saving the TIFFRepresentation into file.

All is good and multicore and fast and I'm almost happy. Anyway I'd need to join those slices back again after I rendered them, to obtain a single TIFF file.

I would try to merge the files using NSInputStream and NSOutputStream but since each file is a complete tiff representation, merging together raw bytes would result in an unreadable picture file. Is there a way to merge image files together without fully loading them to ram, i.e. without using the NSImage methods?

Otherwise I could save raw pixel bytes instead of tiff representations and then join them with NSInputStream/NSOutputStream, but then how could I transform the whole bytes file into a recognizable TIFF without, again, loading the huge thing into ram?

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63
Fabio Cionini
  • 767
  • 6
  • 15
  • I am curious about why you need an image so large - what sort of PDF could have that much information? Another option would be to extract a lower-than-desired resolution (100MB - 1GB uncompressed) image using the technique I outline below and then using some photo editing app to scale it to the larger size. That might give you almost the same image. I'd love to hear what your application is! – Fred Hamilton Nov 24 '10 at 02:26
  • the application is about rasterizing vector graphics into very large bitmaps to create high resolution wallpaper-sized prints. the printing factory needs tiff images and could not handle vector graphics directly. it has to be done in coding though, using Cocoa APIs, not manually. – Fabio Cionini Nov 24 '10 at 09:47

1 Answers1

-1

This technique probably won't work for your extreme demands (see end of message for more on that), but it will hopefully help other people get a much higher res image from a PDF than they could with a screenshot or the snapshot acrobat tool. It's not particularly elegant, but it gets the job done.

Instructions based on Acrobat 9 Reader (earlier and later versions should also work as long as they have the Snapshot/"Marquee Select" tool) on Windows XP. I imagine it applies on most other platforms that run Adobe Reader. (Now that I think about it there could well be alternative PDF display software that can actually just do this without any tricks. Maybe something based on ghostscript?) In any case, I know this works:

  1. Zoom in on the pdf until the image on your monitor has the pixel resolution you're looking for. If you're trying to capture an image with more pixels than you have on your monitor (which is the only reason to use this technique), you will only be be seeing a portion of the image on your screen.
  2. Scroll as needed to find a corner of the PDF you want to capture.
  3. Select the Snapshot/"Marquee Select" tool.
  4. Click the corner, hold the mouse button down (drag-select) and move the mouse to the opposite corner of the window.
  5. The screen will start auto scrolling towards the opposite corner of your image. It may take a while, but it will get there.
  6. When you get to the opposite edge, take your finger off the mouse, and you should have the high-res image in your clipboard.

Now, depending on the "size" of the initial image (Acrobat will only zoom up to 6400% of the original size based on the DPI information in the PDF), this technique could theoretically allow you to get to 100k x 80k pixels. Where it falls apart for most of today's PCs is that you'd need enough RAM to hold 22GB of image data in your copy buffer...

Fred Hamilton
  • 697
  • 3
  • 9
  • 22
  • ahem, I'm sorry but if you carefully read the question you'll find that it was about a method to do that programmatically by using Cocoa APIs, not manually using Acrobat or else... – Fabio Cionini Nov 24 '10 at 09:45
  • True, but if you read my response carefully I do recognize that it probably won't meet your needs. I was hoping that my response/method might be useful to some people who stumble upon this question (as I did) based on the more general subject, and don't mind a little manual labor. – Fred Hamilton Nov 24 '10 at 21:42