QZ-Tray uses height value for width when printing PDF to label printer on MacOS - cuts off printable content

lite1979 commented 2 years ago

Environment:

OS: MacOS Monterey (issue is present on older OSs as well)
QZ Tray: 2.1.6
Config: width: 2.25, height: 1.25, units: 'in'
Java: Adoptium OpenJDK 11, Hotspot
Printer: Zebra GK420d
Paper/Label: 2.25x1.25 label stock (Printer is calibrated for this size)
PDF: Attached here: label3.pdf

Expected results

PDF prints to label stock, scaled and positioned correctly

Actual results

PDF gets cut off on the left and right, printing exactly 1.25" wide and leaving the sides blank (landscape dimensions cropped to portrait dimensions)

Background

Support has gotten used to swapping height and width to get certain small PDFs to print correctly on Mac, but in this case, both the label stock and the source PDF have a width that is greater than the height, and QZ-Tray (on Mac) doesn't seem to honor this, continually using the height parameter for the width and producing an undesirable result.

Additional information

This is exclusive to MacOS, and affects image printing as well as PDF printing. Both Linux and Windows produce expected results.

akberenz commented 2 years ago

When stepping through with a PDFWriter printer on mac with a custom page size of 2.25x1.25, I was seeing the print job report the page size as the inverse (1.25x2.25). Not entirely sure if this was the specific printer, something wrong with my config, or the cause of this issue though.

I've some changes pushed up on mac-pdf-flip branch that fixed what I was seeing, if you could retest with that and see if it addresses this issue at all.

tresf commented 2 years ago

When stepping through with a PDFWriter printer on mac with a custom page size of 2.25x1.25, I was seeing the print job report the page size as the inverse (1.25x2.25). Not entirely sure if this was the specific printer, something wrong with my config, or the cause of this issue though.

I've some changes pushed up on mac-pdf-flip branch that fixed what I was seeing, if you could retest with that and see if it addresses this issue at all.

@bberenz, Didn't we run into something similar here? https://github.com/qzind/tray/issues/12#issue-140880366. Do you think it's related?

Vzor- commented 2 years ago

I can confirm that this issue presents on MacOS but not Windows or Ubuntu. This issue seems to go away if System.setProperty("java.awt.printerjob", "sun.print.PSPrinterJob") is set. I am still looking into the root cause but it seems to be related to which class gets assigned to https://github.com/qzind/tray/blob/2adb4f879a834922e24c58ab3832d47e66355f62/src/qz/printer/action/PrintPDF.java#L175 On MacOS sun.lwawt.macosx.CPrinterJob gets assigned, and on Ubuntu sun.print.PSPrinterJob is assigned. Forcing the class to PSPrinterJob is most likely a bad idea, I am looking into what exactly is going wrong with the CPrinterClass now.

Edit: This fix works with 11.0.9 but not with 15

Vzor- commented 2 years ago

I have made a print test https://gist.github.com/Vzor-/fe9ab75588f3c216360068e94c6a7672

I was able to remove all of our unique code, and I was able to remove PDFBox. That points the finger at Java.

I am going to step through PSPrinterJob and CPrinterJob (and maybe Book) to see if I can find the issue that way.

tresf commented 1 year ago

Filed with upstream (private) JDK provider as QZ-9.

tresf commented 1 year ago

I am going to step through PSPrinterJob and CPrinterJob (and maybe Book) to see if I can find the issue that way.

I'll turn this over to our support provider for now, this should be right up their alley. :)

tresf commented 1 year ago

An upstream JDK patch has been provided: https://github.com/openjdk/jdk/pull/10808

Vzor- commented 1 year ago

These are our old results, top is portrait, bottom is landscape

These are the results with the changes to jdk master 21.0.0

I think there may be some orientation code causing the issue with portrait, If I run a test snippet with the new JDK I get this

kjordan2001 commented 1 year ago

Looks like there was some progress on this in OpenJDK this week. It's merged into 21 and has a pull request for 17. Is it possible to run QZ on 21 right now?

tresf commented 1 year ago

Is it possible to run QZ on 21 right now?

Hmm... We've never tested this, but it's theoretically possible by downloading JDK21 from openjdk and using our new new jlink.java.target option:

ant -Djlink.java.version=21.0.0+0 -Djlink.java.target=$HOME/Downloads/jdk-21.jdk/Contents/Home pkgbuild

To target Intel from Apple Silicon, download and extract the Intel build and specify -Dtarget.arch=x86_64:

ant -Dtarget.arch=x86_64 -Djlink.java.version=21.0.0+0 -Djlink.java.target=$HOME/Downloads/jdk-21.jdk/Contents/Home pkgbuild

I've prepared some builds to share here:

leoburgos commented 7 months ago

I'm having the same problem here, reproduced also with pixel printing and in both MacOS and windows machines.

Environment:

OS: MacOS Ventura QZ Tray: 2.2.3

Config: width: 2, height: 1, units: 'in' Java: Java(TM) SE Runtime Environment (build 12.0.2+10) Printer: RWTS PDFwriter emulator and Canon MP250 series Paper/Label: A4 PDF: Attached here: QZ Tray Pixel Print-26.pdf

Expected results PDF prints to label stock, scaled and positioned correctly. Pdf should be 2x1 inches size. Positioned on the top left corner of the page when using physical printers

Actual results PDF reverses the size measures, printing a 1x2 inches pdf with the design showing "horizontal" as it should be but the PDF being printed "vertically". Depending on the image and sizes sent, printing position changes from bottom left to top center to other weird positions when printing on physical printers.

Background I've tested with emulator and a few different printers, both in Windows and Mac and I get the same results. When printing vertical labels i.e. height being larger than width then it prints correctly as measures don't get reverted, such as this example: QZ Tray Pixel Print-27.pdf

Code snippet: import qz from "qz-tray"; config = { size: { width: 2, height: 1 }, units: "in", .... // default values }; const command = { data: "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAA..." // base64 image, flavor: "base64", format: "image", type: "pixel" } qz.print(config, [command]);

Things I've tried so far:

Swapping size values when sending horizontal images to try to trick it, doesn't work. Different units of measure
Windows vs Mac, emulator vs physical printers
I have also tried installing above's build qz-tray-2.2.2+JDK21-arm64.pkg, got the same results.

lite1979 commented 7 months ago

@leoburgos

Can you please test with sample.html and the JDK21 build? That fact that you're seeing undesired results on both Windows and Mac in your previous tests suggests that something else may be affecting your results.

Using our sample.html inside the demo folder will provide a direct comparison without any additional variables.

lite1979 commented 7 months ago

@leoburgos Also, as I mentioned in my email, please send me a copy of your image file so I can test it locally on similar-sized label stock. lite@qz.io

leoburgos commented 7 months ago

Hey @lite1979 , here's the base64 image that I've used to generate the PDF results shared on my original post test.txt

To be clear, it fails both on Windows and Mac with the current release 2.2.3 version, I haven't tested on Windows with the custom release by @tresf but I did test it on MacOS.

lite1979 commented 7 months ago

Confirmed that the attached test.txt (converted to image.jpg for my test) does not provide an accurate print result using the 2.2.2+JDK21 build when printing to either a Virtual PDF printer or my Zebra GK420d using 2x1" label stock.

I converted the image to a PDF and the results are not accurate (in the same way), same with .png image file.

Edit: 2018 Mac Mini, Sonoma 14.2.1 (23C71)

lite1979 commented 7 months ago

I still think QZ-Tray uses some math to force an orientation swap based on the dimensions provided for PDFs. I see this in the logs consistently on Mac, but I only see it when I get the wrong results when using "default" orientation on Linux (forcing portrait on Linux provides expected results).

Adjusting orientation to print landscape PDF source

For what it's worth, I get the correct results on Mac as well when I use a PDF and force "Portrait" using the +JDK21 build...

Unfortunately, no combination of configs allows me to print a .png or .jpg image with width>height correctly to label stock where width>height at this time.

tresf commented 2 months ago

Some updates on this issue as it pertains to the MacOS Zebra driver...

[Even with the latest OpenJDK patches] we were able to reproduce the issue, but only on the Zebra printer. When I tested a portrait label against the Brother printer from MacOS, the underlying issue was solved.

We have a test-case that we used for acceptance of the bug and it used a virtual PDF printer. We felt that this was a suitable test-case because it offered an accessible unit test to our JDK support provider.

Interestingly enough, the Zebra driver is nuanced on MacOS and requires even future workarounds. This is what we observed:

🚫 FAIL: 1.25 x 2.25 + LANDSCAPE

✅ PASS: 2.25 x 1.25 + PORTRAIT ... However, when we ran these same settings through our OpenJDK bug report snippet, it still fails for the Zebra printer. I'm not sure why.

I was able to create a reproducible test-case using Virtual ZPL Printer (.NET) in a Windows ARM64 virtual machine, so we're prepared with that to use for acceptance testing [without having access to physical hardware]

I'm not sure where the bug resides, but we'll continue working towards something that passes.

qzind / tray