QZ-Tray reverses width and height values when pixel printing wide images

[leoburgos]

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

Sounds related to this other open issue #965, but this one isn't tied specific neither to PDF printing nor to MacOS.

[lite1979]

Closing as a duplicate of #965

Please try one of the jdk21 builds from @tresf 's repo and report your findings there.

[tresf]

Please try one of the jdk21 builds from @tresf 's repo and report your findings there.

Hmm... Related: #1222. I don't think there are any builds. Someone would have to build the jdk21 branch.

[tresf]

Please try one of the jdk21 builds from @tresf 's repo and report your findings there.

Hmm... Related: #1222. I don't think there are any builds. Someone would have to build the jdk21 branch.

Oh, I found them: https://github.com/tresf/tray/releases/tag/v2.2.3

[lite1979]

Reopening because this bug is clearly different from #965

Tested and reproduced on both Linux and Mac using jpeg: results on both OSes are rotated 90 degrees with the jpeg provided.

[ericve25]

@tresf @lite1979 thanks for re-opening here. We've confirmed in our testing with a variety of hardware that this issue seems to occur across Windows and Mac, and on a variety of printer hardware. Let us know if any additional info would help investigating this!

[lite1979]

So I thought I had reproduced this issue on both Linux and MacOS, and I was prepared to see it as well in Windows. Now I can only reproduce the issue on MacOS.

I was writing in shorthand, so to be explicit in what my config was, see the typed out configs below:

All tests: scaleContent: true, rasterize: false, units: inches

Windows:
Orientation: Default
Size: 2x1

MacOS1:
Orientation: Default
Size: 2x1

MacOS2:
Orientation: Portrait
Size: 2x1

MacOS3:
Orientation: Landscape
Size: 2x1

MacOS4:
Orientation: Landscape
Size: 1x2

Linux:

Orientation: Default
Size: 2x1

[lite1979]

I understand that this is not exactly the target printer for your use-case @leoburgos
I will test again using my laserjet and virtual PDF printers for comparison, but I would very much like to see logs for your tests as well.

[tresf]

Although not necessarily intuitive, I was able to get the desired results with the following settings:

{ size: { width: 1, height: 2 }, orientation: 'landscape' }

... both MacOS and Windows seemed to properly print the document. @leoburgos can you test this combination?

[tresf]

The OP messaged me privately and is no longer using this feature. Closing for now. Feel free to request a reopen if it's believed that it was closed in error.