C# QuickPDFDARenderPageToFile throws SEHException

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

A set of PDFs a customer sent us has broken my program for batch converting PDFs to G4 TIFF files at 300 DPI.

The chunk of code affected seems to be:

PDFLibrary pdflib = new PDFLibrary("QuickPDFDLL0816.dll");
pdflib.UnlockKey("my key here");
handle = pdflib.DAOpenFileReadOnly(file, "");
int numpages = pdflib.DAGetPageCount(handle);
for (int j = 1; j <= numpages; j++) {
    int pHandle = pdflib.DAFindPage(handle, j);
    int ret = pdflib.DARenderPageToFile(handle, pHandle, 10, dpi, outputFile.ToString() + " page " + j + ".tif");
}
pdflib.DACloseFile(handle);

When DPI is changed from 300 to 150 it doesn't throw the exception, but rather creates a completely white/empty PDF. I'm running Windows 7 64-bit with 16GB of RAM (although the program is 32-bit and appears to cap out at 1GB of RAM). Is 300 DPI just too much for this document? Is there a way to get a more descriptive reason as to why this error is thrown?

One of the PDF files in the set is available here to look at:
http://dl.dropbox.com/u/11659372/Volume%201%20Combined%202.pdf

From what I can tell the PDFs from the client were created in Adobe Acrobat 9.2 (there's a line about it if I open the PDF in Notepad++ but you may want to check for yourself).

Thanks. Please let me know if I left out any additional information that might be helpful.

Edited by murpium - 14 Jun 12 at 10:14PM

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
murpium Members Profile Find Members Posts Beginner Joined: 14 Jun 12 Location: Texas Status: Offline Points: 4	Post Options Post Reply Quote murpium Report Post Thanks(0) Quote Reply Topic: C# QuickPDFDARenderPageToFile throws SEHException Posted: 14 Jun 12 at 9:49PM
	A set of PDFs a customer sent us has broken my program for batch converting PDFs to G4 TIFF files at 300 DPI. The chunk of code affected seems to be: PDFLibrary pdflib = new PDFLibrary("QuickPDFDLL0816.dll"); pdflib.UnlockKey("my key here"); handle = pdflib.DAOpenFileReadOnly(file, ""); int numpages = pdflib.DAGetPageCount(handle); for (int j = 1; j <= numpages; j++) { int pHandle = pdflib.DAFindPage(handle, j); int ret = pdflib.DARenderPageToFile(handle, pHandle, 10, dpi, outputFile.ToString() + " page " + j + ".tif"); } pdflib.DACloseFile(handle); When DPI is changed from 300 to 150 it doesn't throw the exception, but rather creates a completely white/empty PDF. I'm running Windows 7 64-bit with 16GB of RAM (although the program is 32-bit and appears to cap out at 1GB of RAM). Is 300 DPI just too much for this document? Is there a way to get a more descriptive reason as to why this error is thrown? One of the PDF files in the set is available here to look at: http://dl.dropbox.com/u/11659372/Volume%201%20Combined%202.pdf From what I can tell the PDFs from the client were created in Adobe Acrobat 9.2 (there's a line about it if I open the PDF in Notepad++ but you may want to check for yourself). Thanks. Please let me know if I left out any additional information that might be helpful. Edited by murpium - 14 Jun 12 at 10:14PM

AndrewC Members Profile Find Members Posts Moderator Group Joined: 08 Dec 10 Location: Geelong, Aust Status: Offline Points: 841	Post Options Post Reply Quote AndrewC Report Post Thanks(0) Quote Reply Posted: 15 Jun 12 at 12:38PM
	That is a very large PDF to be rendering at 300dpi in 32bit mode. The page size is 91.4cm x 1.2 metres - ie about 1m square. 10795 x 14505 pixels which requires lots of memory to process and render. I would suggest you compile your app in 64bit mode if possible. I am pretty sure Quick PDF library is having memory issues rendering this PDF. Andrew.

murpium Members Profile Find Members Posts Beginner Joined: 14 Jun 12 Location: Texas Status: Offline Points: 4	Post Options Post Reply Quote murpium Report Post Thanks(0) Quote Reply Posted: 15 Jun 12 at 3:59PM
	Thank you, AndrewC. I switched to compiling in 64-bit and using the 64-bit QuickPDF DLL and that has resolved my problem. The program now jumps up to about 2GB of memory when creating a TIFF and lowers back down to 500MB between conversions. I understand that the output TIFF is gargantuan but I was hoping use of the DA (Direct Access) functions would have helped keep the memory usage lower.

AndrewC Members Profile Find Members Posts Moderator Group Joined: 08 Dec 10 Location: Geelong, Aust Status: Offline Points: 841	Post Options Post Reply Quote AndrewC Report Post Thanks(0) Quote Reply Posted: 18 Jun 12 at 10:15AM
	We will be looking at optimisation of this type of task for the upcoming QPL 9.xx releases.