search

qzind / qz-print

Archive for legacy qz-print versions (1.8, 1.9). See https://github.com/qzind/tray for modern versions.
Other
141 stars 101 forks source link

1.1in x 3.3in Dymo Label Support #183

Closed tresf closed 8 years ago

tresf commented 8 years ago

This bug report has been re-titled and migrated to https://github.com/qzind/tray/issues/12.

Placeholder for testing, configuration and output for 99010 (1.1in x 3.3in, 28mm x 89mm) Dymo label format.

Related: #177

Sample label: (landscape) 3.3in x 1.1in.pdf image

Sample label: (portrait) 1.1in x 3.3in.pdf image

klabarge commented 8 years ago

It appears that changing the orientation setting for PDF's currently does not work.

I had to use an image to test how the orientation setting currently functions.

Config
var size = { width: 3.3, height: 1.1};
var config = qz.configs.create('Microsoft XPS Document', { orientation: 'landscape', units: 'in', size: size });
Original PDF (3.3in x 1.1in)

image

  1. Using the PDF above, I was not able to view any differences between forcing landscape or portrait

    image

  2. However, when I tried doing the same thing with an image, we can see that the image is rotated

    image

  3. Then, when I changed the page dimensions, I got:

    image

    Note: Even after adding a printer with the above dimensions to my operating system, and using the original image that was designed for that size, I was unable to get rid of the gap at the bottom of the image.

tresf commented 8 years ago

I was unable to get rid of the gap at the bottom of the image.

Right, because the dimensions were off by a considerable margin when compared to the label mentioned.

Here's an illustration showing it fixed to a 3:1 ratio...

GREEN: stretch width to be proportional BLUE: shrink height to be proportional

image

changing the orientation setting for PDF's currently does not work.

Confirmed, except mine does portrait orientation every time (using PDFCreator, not XPS).

Upstream convo: https://issues.apache.org/jira/browse/PDFBOX-2922

@bberenz I've spent some time reading up on this and I'm not sure how best to approach the force-orientation in code.

akberenz commented 8 years ago

It looks like PDFBox is internally forcing a swap of dimensions when width > height to avoid the exception thrown by the MediaSize class when this condition is met. We manage to skirt around this issue with image printing by using the MediaPrintableArea class, but as we have no control over the pdf printing logic I'm not sure there is anything we can do here. The XPS printer is a bit .. loose anyways. Have you seen any of the results when using an actual label printer with PDFs?

tresf commented 8 years ago

@bberenz using PDFCreator, this auto-rotates as documented. We have some options...

To quote the relevant portions from the developer...

If you want to customise the orientation, then you don't want to use PDFPageable. The purpose of a Pageable interface is to let the source document determine its own layout. If you want to do something custom, then skip the Pageable and use a Printable directly.

I do much prefer the standard behavior, but how much work is the Printable portions he speaks of? Can we use Printable if orientation is provided and fallback onto Pageable if not?

tresf commented 8 years ago

This bug report has been re-titled and migrated to https://github.com/qzind/tray/issues/12.