Frequently Asked Question:

Return to FAQ Index

I am a new user. Using the latest release 719, I created a one-page PDF with just two 18KB PNG files on it, and saved the PDF, which turned out to be over 3MB in size. I was using AddImageFromStream, and while investigating the problem I saved the stream to disk both before and after this API call. After the call, I found that the API had re-used my stream to hold a bitmap, which saved out as about 500KB. Even two images this size don't come close to 3MB. The solution was to add a CompressImages(1), and this reduced my PDF size to around 50KB, which seems reasonable. But the documentation says that PNG images are compressed automatically and you don't need to call CompressImages. And who said you could mess with my stream? What is going on?

The PDF specification supports JPEG data directly, so you can just put the JPEG directly into the PDF. But it doesn't support PNG data directly so the image data must be read out of the PNG image and only the necessary parts added into the PDF. For the image data itself, the way a PNG stores the data is with a byte prefixed to the beginning of each row that indicates the predictor that was used. So in Quick PDF Library 7.18 and earlier this byte had to be removed - essentially converting the PNG into a "bitmap" format which is really just the raw byte data.

For version 7.19 we added the ability for Quick PDF Library to add the image data as it appears in the PNG (with the predictor bytes) directly to the PDF by making use of an additional entry in the image dictionary specifying that a PNG predictor is being used in the data.

However this doesn't work for all PNG images. For example, the image data inside PNG images that are interlaced cannot be added directly to the PDF because the PDF specification doesn't support interlaced image data.

Regarding the compression of the image data, all the PNG code (even in earlier versions of the PDF library) have been set up to always compress the image data, so I'm not sure why you're seeing uncompressed image data in your case, but we will examine the images and documents that you have sent us directly to find out.

So in summary:

1. PDF doesn't support PNG images directly so the image data must always be converted.
2. In Quick PDF Library 7.19 we added extra functionality to keep as much of the original PNG data as possible by adding support for PNG predictors.
3. Quick PDF Library should always keep PNG image data in compressed format and we're not sure why he was seeing uncompressed data.

As for the issue with your stream being re-used, we will also investigate this, as that should not be happening. I will follow up with you directly in a support case regarding your images and documents.