Sorry nobody triaged this bug earlier. I just saw  bug 660816  yesterday. Would you agree this is the same problem?

You know, it could be related, but I think this is actually due to a margin issue.  Chrome has a default margin on both sides and scales the image to fit.  I should have updated the bug earlier with a bit more information that I gathered from my discussion with Dymo.

It turns out that the native .pdf viewer in Chrome is not exposing all of the available printer's print options.  With a .pdf plugin called 'PDF JS', it correctly exposes a 'more' option where 'margins' is selected as 'default'.  In PDF JS plugin, if you leave this box checked, it behaves as described above, with a compressed output.  If you click on 'none', the label prints out correctly.

Attached are what the PDF and print preview looks like for me with 30330 paper size. Does that match what you see? To be clear, is the print preview ok or not?

Deleted: pdf_viewer.png 7.2 KB

	pdf_viewer.png 7.2 KB View Download

Deleted: preview_no_fit_to_page.png.png 8.0 KB

	preview_no_fit_to_page.png.png 8.0 KB View Download

Deleted: preview_fit_to_page.png 6.9 KB

	preview_fit_to_page.png 6.9 KB View Download

Here's the full print preview. I guess with Chrome 54.0.2840.87	on Windows 7 here, I don't see the problem. I grabbed the drivers today. The driver installer I downloaded is DLS8Setup.8.5.4.exe.

Deleted: print_preview.png 16.4 KB

	print_preview.png 16.4 KB View Download

The pictures that you show is how the first view appears upon opening the .pdf using the built-in viewer.  After clicking the <Print> button in the upper right corner, the image then appears as is shown in the previously uploaded Image1.jpg (which does not match your images).  

I'm on Windows 10, although I'd be surprised if that made a difference.  One thing to note on your image is that it doesn't show the additional printing settings that are available, including margins.  Ultimately getting those settings exposed (as they are with other .pdf plugins) would allow for proper set up of the image... 

There are not additional settings with the Chrome PDF Viewer. If there were, there would be a "more settings" UI element to click on. In both of our print preview screen shots, all the available settings are already displayed.

So I can't explain the difference between Image1.jpg and print_preview.png. I will note if 30330 labels are 0.75" x 2", then the canvas in Image1.jpg is wrong. I wonder if switching from 300x600 dpi to 300 dpi makes a difference?

I changed the quality to 300x300 dpi and it generated the same result.  I remember reading in the documentation that the printing will automatically switch to 300x600 if it is printing an image.

In my exchange with Dymo, they provided the screenshot below that uses third party .pdf extension.  This extension exposes the margin setting (why Dymo claims is a setting that is made available).

Quote from Dymo in regards to their extension 
"When you open the pdf in Chrome, and you click on “Print”, it takes you to another page.  On that page there should be a “More setting” button.  Click the + next to it to get more settings.  One of those settings is “Margins.”  When I changed from “Default” to “None” the barcode expanded to fill the page.  Can you try that?

1: Drag the pdf you sent on to Chrome
2: Press Print
3: The attached screen shows up
4: Press + for More Settings
5: Choose (None) form the Margins drop down.
6: Press Print"

At first they couldn't reproduce it because they were using a third party extension called PDF JS.  After disabling the extension, they were able to reproduce the lack of +More and the margin setting.

Deleted: Dymo2.PNG 43.4 KB

	Dymo2.PNG 43.4 KB View Download

Deleted: Dymopdf.png 60.9 KB

	Dymopdf.png 60.9 KB View Download

+rbpotter who was looking at a similar bug.

I was able to reproduce this. The difference between Image1.jpg and print_preview.png is how the printer quality is set in the OS printer settings. On Windows 10, this is done via Devices and Printers -> right click printer -> Printing preferences -> Layout tab -> Advanced button. If quality is set to 300x300 in this dialog, the preview displays correctly (like print_preview.png). If quality is set to 300x600, the preview displays incorrectly (like Image1.jpg).

Changing the quality setting in the print preview appears to make no difference in the displayed label. Not sure what it would do when printed as I don't have a physical DYMO printer and the label printer I have doesn't have this setting. I will investigate further, but this may be because the value in print preview is ignored. I do not see anywhere in the print preview code that the dpi is read and added to the print ticket.

Given that it appears the difference between good and bad previews is the DPI setting, this is likely a problem with handling non-square DPIs set in the OS printer settings. This may translate to handling non square DPIs in general if the preview dpi is in fact not used.

RE: margins, we don't expose margins when the source is PDF, as we just use the PDF margins (unless fit to page is checked). See https://cs.chromium.org/chromium/src/chrome/browser/resources/print_preview/data/ticket_items/margins_type.js?l=59 - if the page cannot be reflowed (PDFs cannot be), margin settings will not be available. Exposing margins settings for PDF documents would be a new feature, so if that is something you want feel free to open another issue requesting it. It does not look like that is the cause of the bad preview/print however.

Print preview dpi setting is ignored for everything other than cloud, privet, and extension printing. This is noted in  http://crbug.com/429393  where the setting was added. For local printers, dpi is read from the printer in the print settings initializer, and we just take the x direction dpi. There is a comment there noting that rectangular dpi values aren't supported:  https://cs.chromium.org/chromium/src/printing/print_settings_initializer_win.cc?l=114

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/116c2e17ec19ced7c6700c34661017ee81d0d4ab

commit 116c2e17ec19ced7c6700c34661017ee81d0d4ab
Author: rbpotter <rbpotter@chromium.org>
Date: Tue Apr 04 19:21:28 2017

Use DPI from Print Preview on Windows, handle non square

- On Windows, use DPI set in print preview to set the printer DPI. Print
  preview DPI was previously only used for extension/cloud printers.
- Fix handling of non-square DPI - use x and y DPI to compute the
  correct page size to report from the printer instead of assuming
  both resolutions are the same when computing page size. Assuming both
  are identical results in incorrect page sizes for non square DPI.
- Note that we have to use only 1 DPI for rendering in both
  dimensions, this CL just fixes the bad page size behavior.

BUG=648774
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2795453002
Cr-Commit-Position: refs/heads/master@{#461799}

[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/chrome/browser/resources/print_preview/native_layer.js
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_job_constants.cc
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_job_constants.h
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_settings.cc
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_settings.h
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_settings_conversion.cc
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/print_settings_initializer_win.cc
[modify] https://crrev.com/116c2e17ec19ced7c6700c34661017ee81d0d4ab/printing/printing_context_win.cc

Please try out Chrome 59.0.3063.0 or newer with the label printer. Google Chrome Canary will reach that version in a day or two.

I validated on canary 59.0.3063.0.
The print preview appears to be fixed.
The actual printout is still compressed. 

Okay, thanks for checking. That will be trickier to track down/verify since we don't actually have a printer that supports different DPI in different directions. Will keep looking into it.

I'm more than happy to loan you my Dymo printer, especially if you're in the Mountain View area... 

Update: this is still in progress. It turns out that there are some changes to PDF orientation handling that need to be landed first in order to make this work correctly. Currently testing by forcing rectangular DPI settings to be sent from a square DPI printer and used when generating the document sent to the printer, and looking at the final output to see that it is stretched/compressed as expected.

My team has recently started implementing a nw.js based printing system since Adobe plugins are no longer supported, and have come across this problem - printing half width. Unfortunately 300dpi isn't accurate enough to print legible barcodes.

Interestingly, the label we're using is missing from the paper size options, but shows in system dialog.

Is there anything I can do to help move this along?

Is there any improvement in current Chrome Canary or Dev? We have landed some recent changes in Chrome 66 that should remove distortion when printing from rectangular DPI printers, and they seem to work with a Bixolon printer with a rectangular DPI setting that we have here for testing.

Hi, I've just tested on Canary [Version 67.0.3365.0 (Official Build) canary (64-bit)], and although I can see 300x600 dpi as a quality option, it still prints at 300 dpi.

The label size is still missing from the paper size option in print preview - should I report this as a separate bug?

If I try the system dialogue, it does print at 300x600 dpi but is only a quarter of the paper size.

The label size would be good to report as a separate bug, yes. That sounds like Chrome is having trouble getting the list of paper sizes from the printer correctly, which will require a different fix. Please note on the new bug what printer paper size(s) isn't showing up and what printer driver you are using. You can post a link to the bug here afterward if you would like so that we can make sure it gets triaged quickly.

Not sure what is going on with the system dialog. I can't seem to reproduce that here on Canary with a Bixolon printer, which has a 160x72 DPI setting. My guess is that it is either printer specific or that it is somehow related to the horizontal DPI being smaller than the vertical DPI. Unfortunately, we don't have a printer with a smaller horizontal than vertical DPI setting to test with.

The printed quality issue could also be printer specific, as I can see the quality change on the Bixolon printer (from 80x71 to 160x72), and I believe there are certain (non-rectangular DPI) printers where there are problems with setting the quality at the printer, so that could be the case here as well. What printer/driver are you using?

I added my report on the paper size issue to https://bugs.chromium.org/p/chromium/issues/detail?id=57903#c_ts1520517745

The driver was automatically installed when connecting the printer. I've since removed the device and uninstalled the driver, then installed the driver from http://www.dymo.com/en-US/labelwriter-300--400--450-series-print-drivers--windows-vista-7-%2864bit%29-dymo-labelwriter-drivers-64bit-windows-p--1#

I'm using a Dymo LabelWrier 450.

I've done some more testing, and found that changing the printer's defaults to 300x600 prints at 300x600 despite what settings I choose in Chrome's default print dialog. The system dialog prints at the chosen setting. Whether using the default or system dialog, the printout is now the correct scale - this is using the same Canary version, so the driver must have made a difference.

With these changes, I could now manage if I could select the correct paper size.