Printing Problem With Xojo 2017 Release 1.0

I found another problem with Xojo 2017 Release 1.0. My app is able to print out address mailing labels from a list of names and addresses stored in an SQLite database.

I use a modified version of the Example Printing Project that comes with Xojo called Labels under Example Projects/Printing and Reporting/Printing folder.

The code works fine when compiled on a Mac, but when I compile it for Windows and run it on a Windows 10 machine the formatting is completely off.

See Photo

It does not appear to be formatting correctly to the paper size or something. No matter what I do with the code, I can’t get it to print correctly. It’s just really messed up, and sort-of frustrating that something that was working fine is no longer working properly now.

Just to clarify the example image above was taken from the actual Xojo example project for Labels that ships with Xojo. This is not my project.

Since no one seems to know what may be going on, I filed a bug report.

47657 - Printing problem with Xojo 2017 Release 1

We had similar issues with printing in Windows and BKeeney Shorts Reports in Landscape mode. We hope this gets fixed soon. Seems like dimensions are still being reported incorrectly in some cases with the new Windows printing engine.

Yep, same exact problem. Installed 2017 R1 this morning (April 6th 2017) hundreds of reports now fail (printouts are like above - like 75% full size) when compiled with this version. Back to 2016 R3, the only really stable release that I can remember recently. Xojo needs to worry a little less about screwing around with Raspberry Pi and concentrate their resources into taming the IDE and getting the compiler right!!!

The Labels example, being rather old, was hard-coded to use 72DPI rather than getting the actual DPI from the printer. Changing the example to get the DPI from the printer ought to get it back to normal. If you have reports that fail, checking what you use for DPI (horizontal/vertical resolution) might be worthwhile.

I’ve attached an improved Labels example project to James’s case (and it will also be included in 2017r2): <https://xojo.com/issue/47657>

From the Feedback system:

[quote]47538 - HorizontalResolution / VerticalResolution return always 96 dpi regardless of connected printer
Status: Verified Rank: Not Ranked Product: Xojo Category: Framework » Windows

Thomas Goerlitz on Mar 28, 2017 at 10:29 PM
OS: Windows 7 Service Pack 1

Xojo: Xojo 2017r1

Regression: Yes

Steps: The following code should return the resolution of the selected printer, it worked with 2016r3, r4 and r4.1.
Running under 2017r1 it always returns 96 dpi regardless of the printer.

dim g as graphics
dim ps as New PrinterSetup
ps.MaxHorizontalResolution = -1
ps.MaxVerticalResolution = -1
g=OpenPrinter(ps)
msgbox str(ps.HorizontalResolution)+" / "+str(ps.VerticalResolution)

Expected Result:
Resolution of the selected Printer, e.g. 300 dpi

Actual Result:
96 dpi, regardless of the selected printer

Workarounds:
none

Robin Lauryssen-Mitchell on Mar 30, 2017 at 5:14 AM
This behavior has been verified by our testing staff.
Status changed from ‘Needs Review’ to ‘Verified’.

Robin Lauryssen-Mitchell on Mar 30, 2017 at 5:18 AM
Changed category to ‘Framework » Windows’[/quote]

Case 47538 was not a bug, that’s the design of the modern Direct2D API to always return a virtual surface of 96 DPI. We updated the label example on Case 47657 to print correctly on any size paper in current versions of Xojo, which is what this thread was about.

I actually tweaked the code from the example project that Paul posted. As it is, it would not format on the label correctly if you actually printed it to an actual label. It would not fit in the pre-cut borders. The code is different for Windows than for Mac.

In Win32 you have to beef up the font a bit and reduce the X and Y
In MacOS you can leave the font at 9 but you have to increase the X and Y
I did not try it with Win64

Here is the code if anyone is interested.

[code]Dim g As Graphics
Dim p As PrinterSetup

p = New PrinterSetup
If p.PageSetupDialog Then
g = OpenPrinterDialog§
If g <> Nil Then
Dim hDPI As Double = p.HorizontalResolution
Dim vDPI As Double = p.VerticalResolution

Dim pageWidth As Double = p.PageWidth
Dim pageHeight As Double = p.PageHeight

g.TextFont = "Arial"

// Width and height of label in inches
Dim labelWidth As Double = WidthField.Text.Val
Dim labelHeight As Double = HeightField.Text.Val

// Width and height of label in page points
Dim labelPageWidth As Double = hDPI * labelWidth 
Dim labelPageHeight As Double = vDPI * labelHeight 

// Draw as many labels as fit into the size of the page
For x As Integer = 1 To pageWidth Step labelPageWidth 
  For y As Integer = 1 To pageHeight Step labelPageHeight 
    If (y + labelPageHeight) < pageHeight And (x  + labelPageWidth) < pageWidth Then
      
      If TargetWin32 Then
        g.TextSize=14
        g.DrawString(LabelArea.Text, x -20, y - 20)
        
      ElseIf TargetMacOS Then
        g.TextSize = 9
        g.DrawString(LabelArea.Text, x + 40 , y + 40)
        
      End If
    End If
  Next
Next

End If
End If[/code]

So, basically, what your saying is we’re screwed when it comes to printing a graphic to a page, concerning print resolution?

Not at all- but that’s a separate issue from the label discussion here. I’ll keep my discussion regarding printing high res graphics on your other thread.

My apologies. The other thread is more appropriate. Although, the two issues are quite inter-related. Thanks again.