I need help - I can help - Good PDFs shown as 1 blank page

Print Page | Close Window

Good PDFs shown as 1 blank page

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=2161
Printed Date: 26 Jan 26 at 10:39AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Good PDFs shown as 1 blank page

Posted By: RedOctober
Subject: Good PDFs shown as 1 blank page
Date Posted: 18 Feb 12 at 6:52AM

Environment: D7, QwkPdfLib 8.13, XP, Win2003/2008

In my application, I use QuickPDF Lib to display .Pdf files. All the .Pdf files have at least one page, with text and/or images on them. Occasionally, my users experience a bug where the known good .Pdf is displayed as being one blank page. The problem goes away if the user shuts down the application and restarts it.

Is there a bug in 8.13 that is causing this? I've never had this happen before in any previous version of QuickPdfLib. I have not changed any other code. (ie: I upgraded my QuickPdfLib, then he problem appeared)

Replies:

Posted By: edvoigt
Date Posted: 18 Feb 12 at 9:06AM

Hi,

it looks for me as a problem of lost/missing memory-space or anything around. Do you check result of used render-function?

Werner

Posted By: RedOctober
Date Posted: 18 Feb 12 at 2:46PM

Hi Werner,

I've done a complete and exhaustive memory chip check, so I know that the memory chips are good. I use RenderPageToStream with a BMP output. In the reference manual there is a return type of Integer, but no listing of what integer constitutes success for failure. I'll assume that zero is "bad" and non-zero is "good". It would be helpful if the manual described what the problem is if a zero is encountered.

Posted By: edvoigt
Date Posted: 18 Feb 12 at 3:11PM

Hi,

I assume no problem with your harware, but problems inside your program with unfreed memory after using it, so that there is no more enough for rendering. Therefore the advice to check result. It seems to be an error in documentation.

What is written for RenderpageToDC:

0 Page could not be rendered
1 Page was rendered successfully

should be valid for all other renderfunctions too. Most functions of QPL give a zero-result in error-case.

For rendering I see only two basics for error:
- PDF with errors inside - not the case, because it is later working
- not enough memory - therefore I look only in this direction.

I use this RenderToStream too and I have sometimes problems with big (and/or complex) PDF-Pages. It was ever a space-question. Have a look, what is at the same time in memory:
1. PDF-document
2. Streamoutput from RenderPageToStream
3. BMP after filling from stream
4. control, which at last shows the image to the user

After 2. you may perhaps free QPL
After 3. the stream may be freed (BMP holds data)

It is anything in this direction if program shows the image on screen in the first run. And later only if you restart (it means automatically freeing all used memory).

Did you try the same PDFs with an older QPL-version?

In hope to be right and not showing a wrong way,

Werner

Remark: Using DARenderPageToStream helps to reduce needed memory too.

Posted By: RedOctober
Date Posted: 18 Feb 12 at 3:27PM

Your comments are very helpful Werner. I did not even realize I could check for the output (due to missing documentation). Maybe I am doing something dum like asking the Pdf to render page -1 (instead of a + number) or something like that. Now that I know I can check for a failed output, it will guide me closer to the solution. Thank you.

Posted By: AndrewC
Date Posted: 22 Feb 12 at 2:35PM

When you finish with a document make you call QP.RemoveDocument to unload the PDF.

if (LoadFromFile("large.pdf", "") == 1)

{

int docID = QP.SelectedDocument();

// process your PDF here etc..

// finished. Now free the memory.

QP.RemoveDocument(dicID);

}

Posted By: RedOctober
Date Posted: 26 Feb 12 at 8:44PM

To close off this ticket, I have discovered that there is some unknown third party component that is changing the FPU RoundMode to rmDown, away from the default of rmNearest. When the problem occurs, I can programatically fix it, simply by calling SetRoundMode(rmNearest).

Now I know the why, but not the what. I don't know which component is leaving the RoundMode setting in the wrong state. So I am left with sprinkling SetRoundMode(rmNearest) before/after events that I think are suspect.

I am on the right track now, and this work around may be my only recourse.