*writing* a multi-page pdf with Magick++ [SOLVED]

[tsftd]

Just finished a robust PDF-to-Image program, and figured that I could reuse most of the code to replace the old Imagemagick script that I've been using for years to create high-quality PDFs from images. However, the ability to output multi-page PDFs is mandatory, and I have no idea how to handle it.

Assuming that I've read all of the images into memory in a vector, how do I write them into a single PDF? I know how to do it with IM convert, but I've never dealt with IM writing out multi-image formats (though I know that it does support some, like TIFF and MNG), and google/forum searches just turn up a million questions about how to convert multi-page PDFs to images (which is what I've already done).

If someone could point me in the right direction, I'd appreciate it. All that I should need is a link to the relevant documentation, function name, or short snippet.

[snibgo]

See http://www.imagemagick.org/Magick++/STL.html and magick++\demo\demo.cpp somewhere on your hard disk.

[snibgo]

For example, here is a trivial program that writes a two-page PDF from the built-in "rose:" and "wizard:".

Code: Select all

#include <iostream>
#include <list> 
#include <Magick++.h> 
using namespace std; 
using namespace Magick;

int main (int argc,char **argv)
{
  InitializeMagick(*argv);
  
  try {
    list<Image> images;
    Image img;

    img.read ("rose:");
    images.push_back (img);

    img.read ("wizard:");
    images.push_back (img);

    writeImages (images.begin(), images.end(), "out.pdf");
  }
  catch( exception &error_ )
  {
    cout << "Caught exception: " << error_.what() << endl;
    return 1;
  }

  return 0;
}

[tsftd]

Much thanks for the quick response!

I'm already using readImages for the PDF extractor program, so I'm all good. Should have thought of the likelihood of an inverse function...

Just in case someone comes across this with a similar question, here is the relevant snippet from my extractor program:

Code: Select all

std::list<Image> images;
std::list<Image>::iterator position;
ReadOptions options;
readImages(&images,pdf,options);
for(position=images.begin();position!=images.end();position++)WritePage(*position);

[snibgo]

Ha! Yes, if readImages() reads as you want, the function that writes in the same way isn't hard to guess.

[tsftd]

As the documentation on this isn't the best, I thought that I'd share my experiences with writeImages (specifically with PDFs, though it may apply to other formats as well):

1) It is surprisingly fast. I guess that isn't really anything that you'd expect to find out, but in my case (extremely high-quality PDF<->PNG conversions), writeImages is many, many times faster than readImages (at least 10x faster). YMMV with lower settings, of course.

2) There is no ReadOptions equivalent for writeImages. This makes sense, as readImages doesn't have separate objects to manipulate settings on, while writeImages does, but FYI, you can (must) set options on each object in the list -- there is no global method.

3) Unlike what I had found back when I did research on my old convert.exe png->pdf script, writeImages does not appear to embed the images into the PDF as JPGs. It appears to embed them in PNG format, from what I can tell. The primary reason that I assume this is that the quality of the output PDF does not change as the "quality" setting is changed, but the size does change considerably. The reason that this is important is that, between this and point 1, you almost certainly want to always set quality to 100 (it does not default to 100, but 75, as per the documentation).

4) Again, YMMV, but contrary to what might seem like common sense, if you can handle threading properly, you will likely be better manually loading the images than using readImages.

Anyways, thanks again to snibgo for the help (and the interesting stuff on his site), and hopefully all of this will help someone else someday.

[snibgo]

On your point (3): writing PDFs responds to "-compress", eg "-compress JPEG" for jpeg compression.

For PNG compression, the "-quality" setting affects speed of compression and output size (but not quality, which is always perfectly lossless). The default 75 may not be either the fastest or smallest. My "Outputs: speed and size" explores this, for both photos and graphics.

[fmw42]

My "Outputs: speed and size" explores this, for both photos and graphics.

See snibgo's page at http://im.snibgo.com/spdsiz.htm