Q:
We create large-ish (40-50MB) PDFs comprisingly of a single JPEG per
page (say around 1MB compressed), a small number of embedded fonts
(changes depending on the user), and a small amount of text. At the
moment we create the JPEG, write it to disk in a temporary file, and
put it into the PDF using ElementBuilder::CreateImage(). Then at the
end we write out the PDF to a temporary file on disk, then encrypt it
and put it into a ZIP file.
Our basic need is that the JPEG doesn't hit the disk in an unencrypted
form (in-memory is a different matter), so we were thinking if only we
could encrypt the JPEG as it hits the disk, and then teach PDFNet to
decrypt the JPEG when it goes to build it's final PDF. Of course then
the JPEG data in the PDF itself is unencrypted, so we'd need to be able
to encrypt the PDF before it hits the disk too. We thought about
keeping the JPEGs and PDF entirely in-memory, but we think the overhead
might be too much for clients with our minimum spec to handle (they
already have some virtual memory issues). If we do everything in
memory, then will PDFNet keep two copies of the JPEG data -- one in the
PDF::Image, and the other in the memory buffer pointed to in the call
to PDFDoc::Save (const char *&...)? Or is it possible to use
Image::InputFilter in some way?
----
A:
When you create a PDF::Image ( e.g. using Image::Create), the image
buffer will not be duplicated and no additional memory will not be
consumed. Instead the image will be saved to a composite temporary
file. As a result, creating the image from memory is probably not a bad
idea.
At the moment, Image::Create method does not accept a FilterReader so
it is not possible to implement a custom Filter that would decrypt
secured JPEGs on-the-fly, but this is definitely something that we will
include in the upcoming versions of PDFNet. This way you could embed
huge images without consuming much memory.