1. Thomas George
  2. PowerBuilder
  3. Monday, 10 July 2017 17:09 PM UTC

Hi,

I did my first test of using the new native PDF SaveAs type, first with the scripted method from the help file: 

dw_1.Modify ("DataWindow.Export.PDF.Method = NativePDF!")
dw_1.Modify ("DataWindow.Export.PDF.NativePDF.CustomOrientation = 2")

dw_1.Modify ("DataWindow.Export.PDF.NativePDF.CustomSize = 4")

 

and the second time just in the DataWindow painter by following the steps also from the help file. However, in both cases, I'm getting a blank page in the PDF after each real page in the report. It print-preview's fine in PowerBuilder 2017, and I also tested by printing to a PDF "printer" in Windows, and I'm not getting the blank pages there.

 

It's the same behavior you see when you have controls in the DW too far to the right and you start getting two horizontal pages in print preview, only my print preview looks fine. Is there some kind of margin setting or some other setting that could be causing this?

 

Thanks,

Tom George

 

Accepted Answer
Brad Mettee Accepted Answer Pending Moderation
  1. Tuesday, 11 July 2017 13:58 PM UTC
  2. PowerBuilder
  3. # Permalink

Try changing your Custom Size from 4 (A4) to 5 (Letter).

You can see the available sizes by going to the Datawindow Data Export tab, change Format to PDF, Method to NativePDF, and drop down the paper size list.

(It would have been less confusing if the CustomSize setting matched the normal print specification size parameter.)

Comment
  1. Thomas George
  2. Tuesday, 11 July 2017 15:29 PM UTC
Hi Brad,



Thanks for the response. This worked for me on my test example. This might be a more feasible solution for me since I have 500+ reports that I'd rather not touch. I can modify the DW dynamically before the SaveAs.



Thanks,



Tom

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 10 July 2017 18:48 PM UTC
  2. PowerBuilder
  3. # 1

Hi Tom;

   Sounds like the same issue even when using GhostScript if your data output (say the last column on the right hand side) is wider than the total PDF document width setting. Note that its not necessarily the column's data length - its the overall column length that might force the spillage over the maximum horizontal size - which then causes the blank page. A quick test would be to significantly decrease the RH column size in the design pane and see what happens to the blank pages when you run the PDF generation again.

   If the column reduction works, then you just have to tweak / play with the overall DWO's width object wise.

Note: Check your overall object width as well in the Header, Summary & Footer bands.

Regards ... Chris

Comment
  1. Thomas George
  2. Tuesday, 11 July 2017 12:39 PM UTC
Hi Chris,



Thanks for the message. I tried your suggestion and that worked. I then proceeded use a vertical line in a single X position to do a binary search of what worked vs. what didn't, and I discovered that on a portrait page, X position 3415 is the maximum that worked, and 3419 or higher forced the blank page. (Print preview for my default printer allows a maximum X position near 3502 without causing the issue.)



I still need to determine the X position for a landscape report, too, and then go back and adjust my 500+ reports, if possible, to make it work.



Unless there is another way to adjust the PDF margins programmatically.



Thanks again,



Tom

  1. Helpful
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Monday, 10 July 2017 19:28 PM UTC
  2. PowerBuilder
  3. # 2

I like to change objects to box border and then turn on print preview mode. Makes it easy to tell if any objects are too far to the left.

Comment
There are no comments made yet.
Richard Lynskey Accepted Answer Pending Moderation
  1. Monday, 10 July 2017 19:45 PM UTC
  2. PowerBuilder
  3. # 3

In addition to what Chris and Roland said, one thing we've found in the past is that when PowerBuilder first calculates the margins, it uses the default windows printer (or whatever printer the PB app itself has since been told to use). When you then go to print, it recalculates them using the actual physical margins the printer things it can handle. As an example, when designing some forms that have tight margins (think IRS style forms with boxes everywhere imaginable), sometimes our margins work great on our local PDF writer, but not the local HP printer. It's possible that the Distiller reports narrower margins than your installed PDF printer uses.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.