Other people have mentioned this as well in the Reports forum (they said the images were being printed as black boxes).
Someone commented that it may have something to do with how much memory the program uses to generate the report and that a lot of images cause it to full up too quickly.
Unfortunately the only workaround found was to print the report a few pages at a time.
There's a new update due out soon - if it still happens after that I'd post again so Ken can take a look at it.

Question: can you try this with multiple printers? I'd be curious if it's the same result.

Or, can you try "printing" to a PDF converter (like the free CutePDF), and see if you get the same result?

This happened to me many moons ago (version 2), but was subsequentlly fixed by an update.

If I may contribute my two cents to the black images problem - some facts; no conclusion:

- I can't agree with the "memory theory", it also appears with a fresh started DVDP an only one profile to be printed. - not always but sometimes.
- It has nothing to do with the state of windows: It also appears on a fresh started Windows with 2 GB of Memory, while only DVDP is started.
- I haven't found a relationship between this problem and the printer(driver). - The problem exists with at least two types of Canon Inkjet printer drivers (2004, and 2006) - color, Kyocera KX Driver - bw, Kyocera PCL Driver - bw, Kyocera KPDL driver - bw - and the Adobe Postscript driver which is used by Ghostscript.
- As far as I can see the problem has something to do with caching: if a image fails to be printed, it is very likely that it fails on subsequent trials. - For me it is the best strategy to print some completely different profiles and get back to the misprinted some time later.
- It has nothing to do with the size of the image, but it seems to be somehow related to the image, since I found some images to be very exposed to this bug, while others are printed all the time...
- Maybe it could have to do something with timing. - I found that it works better when I wait until the job is printed (deleted from the print queue) until I start the next job...
- I weren't able to prove any relation with the harddisc or the speed of the harddisc - the problem exists on a local harddrive as well as on a network drive with either 100MBit or GBit...

I've never reported this bug since I have no clue where to start debugging... But maybe someone reading this thread can combine our ovservations and elaborations to a image which makes sense...

Regards, AA