Has anyone successfully Set/Get FILE Page Boxes?

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

   It is probable that I just don't understand PageBox/CropBox operations, but the results I get just don't make complete sense to me.

Pretty clearly, there are (or may be) "CropBox"es in a pdf file.  If I load a file, select a page, set CropBox, save to file, -- something reasonable is set in the file, and Acrobat DOES respond sensibly to it, and subsequent QuickPDF load/render operations are sensible.

Also, pretty clearly, if I take that modified file, load it and select a page, a "GetPageBox" of type 2 (CropBox), does NOT return the modified page box, but does return a (0,0,w,h) type of box which seems to reflect what the first cropping operation did (effectively reducing the visible page size).

Taking the modified file and applying another cropbox operation to it and saving the file produces a significantly odd result of cropping the modified box, rather than re-cropping the original file page.  This means that once cropped in the file, it can never be "uncropped" -- the window can only get smaller and smaller with subsequent file operations.

Specific problems:
1. I have not been able to set any pagebox on any page, save to file and then fetch any page box and see the modified values.  Something does appear to be written to the file, I just can't fetch it back.
2. Since I can't retrieve the values from the file, I can't theorize what is happening, but a second, or subsequent load/setpagebox/save operation produces extremely odd results.
3. I can not find any sequence of operations that allow me to "un-crop" a page.

Some assumptions I am making (which may not be relevant)  I'm using v15.11 library with Delphi 7, Windows 7 & 10.
1. "CropBox" is the same as "PageBox" type 2 (and use is interchangeable). I am not making that assumption during this testing, but I wonder if it is valid.
2. The various "boxes" are windows into the pdf file page, rather than actual cropping operations which would remove things that are not visible.
3. There are (or may be) each of those various boxes on each page.
4. I'm being very careful not to mix DA and non-DA operations.
5. I use a TopLeft origin, but none of my symptoms seem related to that. 
6. I have not seriously tested the DA functions to see if they cause the same problems - had problems early in that line of testing and have not followed up.

Related oddities.
1. SetPageBox and DASetPageBox have different call sequences - the non-DA uses Left,Top,Width,Height and the DA uses X1,Y1,X2,Y2: which seems odd.  

Footnote:
Kludge work-around.  If I absolutely have to, I can keep a set of master pdf files and create copies, setting a CropBox in the copy.  If I want to change the CropBox, I could copy the master file and set the cropbox to the different value.  This would do what I need to do, but it doesn't seem "right".  The "first" cropbox operation produces a sensible result, but modifying that resulting file does not work sensibly.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
HNRSoftware Members Profile Find Members Posts Senior Member Joined: 13 Feb 11 Location: Washington, USA Status: Offline Points: 88	Post Options Post Reply Quote HNRSoftware Report Post Thanks(0) Quote Reply Topic: Has anyone successfully Set/Get FILE Page Boxes? Posted: 01 Jun 18 at 3:12PM
	It is probable that I just don't understand PageBox/CropBox operations, but the results I get just don't make complete sense to me. Pretty clearly, there are (or may be) "CropBox"es in a pdf file. If I load a file, select a page, set CropBox, save to file, -- something reasonable is set in the file, and Acrobat DOES respond sensibly to it, and subsequent QuickPDF load/render operations are sensible. Also, pretty clearly, if I take that modified file, load it and select a page, a "GetPageBox" of type 2 (CropBox), does NOT return the modified page box, but does return a (0,0,w,h) type of box which seems to reflect what the first cropping operation did (effectively reducing the visible page size). Taking the modified file and applying another cropbox operation to it and saving the file produces a significantly odd result of cropping the modified box, rather than re-cropping the original file page. This means that once cropped in the file, it can never be "uncropped" -- the window can only get smaller and smaller with subsequent file operations. Specific problems: 1. I have not been able to set any pagebox on any page, save to file and then fetch any page box and see the modified values. Something does appear to be written to the file, I just can't fetch it back. 2. Since I can't retrieve the values from the file, I can't theorize what is happening, but a second, or subsequent load/setpagebox/save operation produces extremely odd results. 3. I can not find any sequence of operations that allow me to "un-crop" a page. Some assumptions I am making (which may not be relevant) I'm using v15.11 library with Delphi 7, Windows 7 & 10. 1. "CropBox" is the same as "PageBox" type 2 (and use is interchangeable). I am not making that assumption during this testing, but I wonder if it is valid. 2. The various "boxes" are windows into the pdf file page, rather than actual cropping operations which would remove things that are not visible. 3. There are (or may be) each of those various boxes on each page. 4. I'm being very careful not to mix DA and non-DA operations. 5. I use a TopLeft origin, but none of my symptoms seem related to that. 6. I have not seriously tested the DA functions to see if they cause the same problems - had problems early in that line of testing and have not followed up. Related oddities. 1. SetPageBox and DASetPageBox have different call sequences - the non-DA uses Left,Top,Width,Height and the DA uses X1,Y1,X2,Y2: which seems odd. Footnote: Kludge work-around. If I absolutely have to, I can keep a set of master pdf files and create copies, setting a CropBox in the copy. If I want to change the CropBox, I could copy the master file and set the cropbox to the different value. This would do what I need to do, but it doesn't seem "right". The "first" cropbox operation produces a sensible result, but modifying that resulting file does not work sensibly.

tfrost Members Profile Find Members Posts Senior Member Joined: 06 Sep 10 Location: UK Status: Offline Points: 437	Post Options Post Reply Quote tfrost Report Post Thanks(0) Quote Reply Posted: 02 Jun 18 at 11:09AM
	I agree that it doesn't seem 'right'. I have a task to do shortly which may involve similar operations, but I do not have time to try it immediately. Have you tried throwing a NormalizePage into the mix?

HNRSoftware Members Profile Find Members Posts Senior Member Joined: 13 Feb 11 Location: Washington, USA Status: Offline Points: 88	Post Options Post Reply Quote HNRSoftware Report Post Thanks(0) Quote Reply Posted: 02 Jun 18 at 2:08PM
	actually yes. It was my last-week's project that had a rotated page that was driving me nuts, and NormalizePage was significant in fixing that problem, so I put it in my standard open/load sequence as the default. I would like to locate some file for testing that has an actual pagebox already set into it by Acrobat or some other source. It bothers me that GetPageBox always returns a 0,0,pagewidth,pageheight type of response. The minimal QuickPDF documentation on this topic suggests that this is what you would get if there were no boxes present at all. I am not out of trial-and-error things to try, but clear progress is elusive. I need a clear definition of what does work and what does not.

HNRSoftware Members Profile Find Members Posts Senior Member Joined: 13 Feb 11 Location: Washington, USA Status: Offline Points: 88	Post Options Post Reply Quote HNRSoftware Report Post Thanks(0) Quote Reply Posted: 02 Jun 18 at 3:59PM
	Progress????? Trial and ERROR testing - Original file created by MS Word, 8.5x11 paper, 2 pages - test on copy of file. Create/load file (set UL origin and inches), select all pages one at a time, set each page (SetPageBox BoxType=2 - 4 calls, one for each dimension) to explicitly Left=1.00,Top=0.00,Width=8.50,Height=11.0. At this point I do not explicitly set right and bottom, maybe I should, but this seems redundant. FIRST run on the file produces the "correct" output - what appears to be the pages shifted to the left by 1 inch. Both QuickPDF load/render and Acrobat Reader appear fine. NOTE: the modified file returns a "CropBox" of (0.00,0.00,8.5,11.0), NOT the (1.00,0.00,8.5,11.0) I would expect. Since (in theory) I am just setting a absolute viewing windows into the file page - the "CropBox", I would really expect the GetPageBox values to reflect the change. It gets odder If I make more runs of setting the crop boxes to the exact same absolute values of 1.00,0.00,8.5,11.0). Theory would say that this should have no additional effect, since I would be setting the values to what they already were. Oddly, this does seem to be the case for pages 2 and onward, but page 1 acts differently. Each time I apply the PageBox with the left=1.00, page 1 shifts 1 inch to the left, but pages 2 and on stay the same as they were. (I am assuming pages are always 1 through pagecount, but this is the sort of error that would occur with 0-based numbering). No matter how many times I run the test on a single copy of the file, the GetPageBox returns are always the same (0,0,8.5,11). I ran a variation of these tests to act more like setting a viewing rectangle into the page, rather than a page shift, but the results are odder without adding much insight into the problem. I had assumed that PageWidth and PageHeight were more or less absolute values from the file, but they appear to be cropbox dependent. The significance of this is that, once a cropbox has been applied, the original pagewidth and height are gone (forever). So - there are at least two interrelated mysteries/bugs/features (choose one). 1. GetPageBox/SetPageBox execute, but do not appear to do what one would expect. 2. Page 1 acts differently than all of the other pages. I'm not sure that any of this problem is actually a QuickPDF "bug". What I was trying to do is not a particularly "normal" type of operation, so I may be the only one who has run into this. Specifically, what I was trying to do was determine a CropBox that I would want to apply to a set of files and pages, for a particular file source that I do not control. I was trying to do that by trying a box and then nudging it one way or the other or changing size until I was happy with the result. I was expecting the GetPageBox/SetPageBox to make this job easy, but the results were not at all what I was expecting. I do have a kludge work-around, but I thought I would try to clarify the problem for Debenu's benefit. It is possible that a "fix" would be undesirable, since other developers may be counting on the existing odd behavior. A totally different kludge would be to load the file, insert a dummy page for page 1, apply the cropbox to all pages, and then remove the page 1 before saving. This ought to fix the page1 problem, but not the other one. I still can't obtain the original page size without going to the original file. I'm still looking for suggestions, but I think I will go back to the kludge solution and continue with the project.