Report Behavior when sending to PDF 2

[Scott24x7]

Hi all,
I just experienced an odd issue. I have an app that I've been running for months, and it works fine on the desktop, but on my laptop, when I run the report, (which prints to a PDF), the PDF is cut off at the right about about 1 inch of the normal visible text. It's very odd. The report is set for A4, and that was how the layout was designed. I print it to PDF using Acrobat PDF driver (with a full version of Acrobat on the PC).

Any idea what could be causing this?


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[TamarGranor]

Probably a difference in the printer driver.

Tamar

 

[TheProgrammerGuy]

I used to occasionally have problems sending reports to different printers. There is a command you can send to reset or clear printer properties (? I don't remember exactly what it was for) before you send the print job. Unfortunately, I can't remember what it is, but perhaps someone here will know and post it.

 

[Olaf Doschke]

As a PDF Printer just acts like it is printer hardware, it also has to fulfill several properties of a real printer - or more precise a real printer driver. It has to have a physical printing area, etc.

So I guess it's just a setting of that and you might find it buried in any tab and sub section of the Adobe printer settings.

Ot it would need to be in the saved printer environment of your FRX,

Both things usually don't change. But that's the thing with behaviour changes: They have to come from some change. Any recent Adobe PDF update could be more probable than a recent FRX modification, but you know that better. FRXes also have the bery general setting of Print area to pick between "Printable Area" and "Whole page". I'd look into that FRX setting first.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[StefanFoerner]

Hi Scott,

I would say thats a problem with the PDF printer driver

try the Bullzip PDF printer driver (this is the free version):

[URL unfurl="true"]http://cdn.bullzip.com/download/pdf_free/Setup_BullzipPDFPrinter_11_11_0_2804_FREE.exe[/url]

Regards, Stefan

 

[Scott24x7]

Hi all...
Something to be aware of, and I wonder if others might confirm this.

It took several weeks, but I have finally figured out the issue.
It had nothing to do with printers or drivers.
It was a Windows10 issue. I'm using both a desktop and a laptop that have 4K monitors. On the PC, the size of my monitors is very large (43"), so changing magnification isn't an issue. But on the laptop, I had the zoom setting at the Windows level (Right click, select "Display Settings") and then under Scale and Layout, I had it set on one monitor to 150% (the primary monitor). I have a 2nd 43" monitor attached to it as well, at 100%, but it made no difference. Amazingly, setting this display setting down to 100% from 150% changed the printed output, BOTH for a PDF print, and print to my Canon laser. Very surprising.

But, this is the only thing that required changing to get it to work.
Can anyone confirm this? Has anyone else experienced this?


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Koen Piller]

Hi,

Amazingly, setting this display setting down to 100% from 150% changed the printed output, BOTH for a PDF print, and print to my Canon laser. Very surprising.

Yes I confirm. Setting the display to > 100% can result in this.

Koen

 

[Scott24x7]

That's really annoying.
Is anyone aware of a fix for this?


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Olaf Doschke]

I see, the general scale factor also causes other problems, eg look at tabs of a pageframe.

This is something I forgot to have forgotten earlier. I think in foxypreviewer it can be adjusted as you have more source code of that than from the usual report rendering engine. I think it was a known and then fixed bug.

And that does not only mean the PDF printing functionality of foxypreviewer for its own PDF output, but also the general report preview and print rendering it does. so foxypreviewer in conjunction with any PDF printer like Bullzip or Adobe or PDFCreator.

But you'd have to fix more in the VFP runtimes to make VFP compatible with the general Windows display scaling. I guess it's one of the things MS gave up upon adjusting in VFP even for Vista already. It may even affect VFP on XP, I'm not sure, but that's where we already got minor graphical problems due to ClearType font handling.

As high DPI displays are becoming a norm, this is an issue you're facing as one of the things eroding VFP.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Hi,

Is anyone aware of a fix for this?

I dont think so. The best possible solution is to reset the scale before you construct a report to 100% and reset it afterwards.
I dont think that mr. Chen has not yet made an alorgithm to correct this.

Best regards,

Koen

 

[Scott24x7]

Olaf,
Agree, thanks very much. It was because I had a 2nd monitor attached and realized that I was seeing similar artifacts when dragging the command window around (i.e. the shadow doesn't match the location on a scaled screen), that caused me to think that just maybe this had some issue. It is annoying still that the screen I had VFP on was not scaled, but the main monitor was, and that caused the issue. I might see if I swap that around if it still persists. I have a feeling it won't if the main screen is normal scaling, while a secondary screen is scaled, but I'll validate and reply back.

You are right though, this is too bad that it is eroding VFP in its already venerable state.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[atlopes]

Scott,

There are a few things you may try, nevertheless.

The simplest is to issue these commands as close as possible to the start of your application, preferably before any output is sent to the screen:

DECLARE INTEGER SetProcessDPIAware IN WIN32API
SetProcessDPIAware()

 

[Scott24x7]

atlopes,
Brilliant. Added this in in my early startup code, and the issue of zooming went away (verified by taking it back out again while video zoomed in to 150%).
Thanks, great trick.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Scott24x7]

atlopes,
BTW, where is this documented? Would like to understand more about controlling WIN API properties.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[atlopes]

Scott,

The obvious start is the documentation on the SetProcessDPIAware function at Microsoft, located here:

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocessdpiaware

(a general discussion of the problem:

https://docs.microsoft.com/pt-pt/wi...-desktop-application-development-on-windows).

 

[atlopes]

Scott,

Now that you know that this works, you should probably have a look at the recommended method of declaring your application's DPI awareness, which is the association of a manifest file to your application.

Using this method, even before any single window is created by your program the system already knows that your application is DPI-aware. This will prevent the kludge appearance of screen objects that you may experience with the API call method (because they were prepared with a different text scale).

The following code demonstrates how this can be done, and how your DPI-aware application compares to a standard VFP application. The code of the application is the same in both versions (DPI-aware manifest and VFP standard manifest).

* demonstrate the impact of a DPI aware setting in manifest files

* run in a system with text size setting > 100%

LOCAL Source AS String
LOCAL Manifest AS String
LOCAL SafetyStatus AS String
LOCAL DefaultStatus AS String
LOCAL TempDir AS String

m.DefaultStatus = SET("Directory")
m.SafetyStatus = SET("Safety")

SET SAFETY OFF

* the folder can be safely emptied afterwards
m.TempDir = ADDBS(SYS(2023)) + "thread-pdf-printing-dpi"
IF !DIRECTORY(m.TempDir)
	MKDIR (m.TempDir)
ENDIF
SET DEFAULT TO (m.TempDir)

* delete any existing manifest, just in case
DELETE FILE "test-pdf-printing.exe.manifest"

* the executable main program source (indented for clarity)

* this program fills a cursor with enough data to spread over a page (hopefully)
* of a quick report
TEXT TO m.Source NOSHOW FLAGS 1

	SET REPORTBEHAVIOR 90
	SET SAFETY OFF

	CREATE CURSOR Test (idRecord Int AUTOINC, ContentsInAMemoField Memo)

	LOCAL Records AS Integer
	LOCAL Word AS String
	LOCAL Words AS Integer

	FOR m.Records = 1 TO 3

		m.Word = ""
		FOR m.Words = 1 TO INT(RAND() * 50) + 1
			m.Word = m.Word + REPLICATE(CHR(RAND() * 28 + ASC('@')), INT(RAND() * 10) + 1) + " "
		ENDFOR

		INSERT INTO Test (ContentsInAMemoField) VALUES (TRIM(m.Word))

	ENDFOR

	CREATE REPORT "pdf-printing-dpi" FROM Test FORM

	REPORT FORM "pdf-printing-dpi" PREVIEW

ENDTEXT

* save the program
STRTOFILE(m.Source, "test-pdf-printing.prg", 0)

* create a project with nothing but the program
BUILD PROJECT "test" FROM "test-pdf-printing.prg"

* and generate an executable with the standard VFP manifest
BUILD EXE "test-pdf-printing-standard-manifest.exe" FROM test RECOMPILE

* create a DPI aware manifest
TEXT TO m.Manifest TEXTMERGE NOSHOW
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
		xmlns:v3="urn:schemas-microsoft-com:asm.v3"
		xmlns:ws="[URL unfurl="true"]http://schemas.microsoft.com/SMI/2005/WindowsSettings"[/URL]
		manifestVersion="1.0">
	<assemblyIdentity 
		version="1.0.0.0" 
		type="win32" 
		name="PDF printing test" 
		processorArchitecture="x86"
	/>
	<description>Testing PDF printing with DPI aware setting</description>
	<v3:application>
		<v3:windowsSettings>
			<ws:dpiAware>true</ws:dpiAware>
		</v3:windowsSettings>
	</v3:application>
	<dependency>
	    <dependentAssembly>
	        <assemblyIdentity
	            type="win32"
	            name="Microsoft.Windows.Common-Controls"
	            version="6.0.0.0"
	            language="*"
	            processorArchitecture="x86"
	            publicKeyToken="6595b64144ccf1df"
	        />
	    </dependentAssembly>
	</dependency>
</assembly>
ENDTEXT

STRTOFILE(m.Manifest, "test-pdf-printing-dpi-aware.exe.manifest", 0)

* use the project but generate a new executable
BUILD EXE "test-pdf-printing-dpi-aware.exe" FROM test RECOMPILE

* restore settings
SET DEFAULT TO (m.DefaultStatus)
IF m.SafetyStatus == "ON"
	SET SAFETY ON
ENDIF

* open the project folder in Windows explorer
RUN /N explorer "&TempDir."

* now, execute both programs and see the difference