Report in portrait on landscape paper

questions
1

At a client I have a report that is setup to print portrait direct to PDF (netscape web app),
but when viewing the PDF the paper orientation is landscape, so my portrait report prints on the LHS and truncated at the bottom of each page.

I know I’ve come across this before and I’m sure it was the default printer properties. But I can’t reproduce the problem.

And pointers ?

2

Have you obtained a copy of the original PDF?

What technique are you using to create the PDF? Sorry, I don’t know what a “Netscape web app” is?

3

Nettalk web app sorry.
Just using the std SV PDF reporter templates

4

Do you have a default printer defined? When Clarion can’t get a DC from the printer driver it defaults to a DC from the monitor… ie: landscape.

1 Like
5

I seem to recall there’s a further twist if your NetTalk server is running as a service and generating reports as part of it’s duties. Run it under the default SYSTEM account and things don’t work (DC-wise, the stuff Lee is referring to). Can be fixed by running it using a valid username/password .

Been a while and no reason to think that’s the problem here but worth mentioning…

6

That’s the way to have user defaults!

7

Ah. Now that might be an interesting line to ask them about.
Thanks

8

One of the controls on your report is over the 8500 limit on the x axis. (too wide or too far right)
Check your control placement.
Use fixed width controls that aren’t tempted to resize bigger if the text doesn’t fit.

9

Sorry but that does not have anything to do with the orientation of the report page. If something extends beyond the printable area it simply isn’t printed. Just like placing a control on a window where the control exceeds the width or height of a window, it doesn’t resize the window at runtime.

10

Is it running on Windows Server?

I learned recently that a common “security good practice” in Windows Server is to permanently disable the spooler service, because there was a vulnerability in 2021.

I’m pretty sure the vulnerability was patched a long time ago, but the “good practice” remains and there is no way to convince administrators to change it.

I had to add a hack to PDFTools to detect if the “printer” resolution was 1920x1080 and adjust the PDF layout:

    LOOP pg = 1 TO PDFMgr.PagesNumber()
      PDFMgr.GetMediaBoxForPage(pg,l,b,r,t)
      IF r = 1440 AND t = 810     !No print spooler, monitor resolution 1920x1080 96dpi in 72dpi
        PDFMgr.SetMediaBoxForPage(pg,0,0,612,792) !8.5x11 in 72 dpi pts
      END
      IF r = 810 AND t = 1440     !Landscape
        PDFMgr.SetMediaBoxForPage(pg,0,0,792,612) !11x8.5 in 72 dpi pts
      END
    END
1 Like
11

I agree that’s the way it should work. But I’ve seen that problem, maybe it was an earlier version of Clarion. Even if the orientation was explicitly set to portrait, it would print in landscape because one of the controls was outside the right boundary and the page wasn’t using the full height.

1 Like
12

I’ve been stuffing extra data into a report page since I released AFE for faxing. And a lot of that information exceeds the boundaries of the paper size - considerably. :slightly_smiling_face:

The only way the orientation can be changed once CreateDC has been called is with a ResetDC issued with a different DevMode. If someone issues an ENDPAGE() they are forcing a call to ResetDC which forces a page overflow.

Yes, if you understand the functionality of the creation of a report within the Windows API it’s easy to figure out what’s wrong in this situation - it’s the wrong DC since it’s created to fit the display.

If you understand ResetDC you can, within one report, change the paper size, its orientation and its source but nothing will print beyond the confines of the paper selected in the DevMode.

I’m not saying something untoward crept in somewhere but Clarion uses the Win32 API’s to handle creating report pages and the DevMode and DC are key to this behavior.

13

I’m just relaying my experience from 10 years ago.

I think the underlying printer driver had “zoom to fit” or “fit to margins” set or some such setting.

Since we were only printing about 7 inches of height, but one control went outside the 8.5 inch width, it kept flipping the orientation even though it was explicitly set.

I know the only change we made to fix the problem was fixing the bad control to only print within the allowed width.

Didn’t make sense to me then, and it doesn’t now. But I moved on.

Jim