I need help - I can help - Problems drawing on a PDF

Print Page | Close Window

Problems drawing on a PDF

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=2698
Printed Date: 28 Oct 25 at 2:05AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Problems drawing on a PDF

Posted By: Kudermann
Subject: Problems drawing on a PDF
Date Posted: 02 Aug 13 at 11:23AM

Hi,

i have a PDF where the function DrawBox returns 1. But there is nothing painted on the PDF after i save it and open it.
The security info of the document show me the following results:
Security Method: None
User Password: No
Owner Password: No
Printing: Fully Allowed
Changing the Document: Allowed
Content Copying or Extraction: Allowed
Authoring Comments and Form Fields: Allowed
Form Field Fill-in or Signing: Allowed
Content Accessibility Enabled: Allowed
Document Assembly: Allowed
Encryption Level: Blank
Opened with User password: No
Opened with Owner password: No
Variable Encryption Strength: None

The DrawBox functions works perfect for other PDFs with the same security info results. Only this PDF doesnt work.
Now the question: what can be the reason for this behaviour and how can i check it?
I am using Debenu Quick PDF Library 9.15

No problem to upload the PDF for further tests.

Jutta Kudermann

Replies:

Posted By: AndrewC
Date Posted: 04 Aug 13 at 9:05AM

Jutta,

Can you try calling QP.NormalizePage(0); before calling DrawBox ?

If it works then NormalizePage will need to be be called once for each page that you want to use DrawBox, DrawText etc..

Andrew.

Posted By: Kudermann
Date Posted: 05 Aug 13 at 8:24AM

Hi Andrew,

thank you very much! Thats the solution.

Jutta

Posted By: Eric24
Date Posted: 18 Aug 13 at 7:33PM

Just curious, but why is this is the solution?

Posted By: Ingo
Date Posted: 18 Aug 13 at 10:07PM

Cause there's something special with this single pdf.

Something curious happened while creating ... who knows?

We don't have this pdf - so we won't know.

But this all doesn't matter cause we've a main medecine "NormalizePage" ;-)

Posted By: AndrewC
Date Posted: 19 Aug 13 at 1:07AM

Eric,

PDF files were never designed to be manipulated. They were almost designed as a readonly format until people want to start doing useful things with their PDF files such as splitting, merging, stamping etc..

When you create a new PDF it will start off with the origin point (0,0) in the bottom left corner, the rotation in 0 degrees and the units as points (ie. 72points per inch), a black pen and a white background. Many PDF's change these values in the content stream during the creation process. If is good practice to call SaveState ('q') as the very first call in the content stream and RestoreState ('Q') as the very last operation. Many PDF produces do not do restore the graphics state at the end so when DQPL appends drawing commands such as DrawText it can be affected by the unknown drawing state and so can be drawn at the wrong angle in the wrong color in the wrong position or even off of the page in many cases.

NormalizePage is designed to place SaveState/RestoreState commands at the start and end of the contentstream(s) respectively so that the drawing state is known and can be trusted. NormalizePage works on 99.9% of problem PDF's and it generally recommended to be called before adding any text, graphics or logos to an existing PDF file. Sometimes PDF producers add more SaveState calls than RestoreState calls so NormalizePage(1) will attempt to count and then balance out the Save/Restore calls.

Andrew.