-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML + printer driver sizing #193
Comments
So this is actually working as it should, just not how you are expecting. In the first print the html page size is actually set to the printer default (at that point Letter, 8.5x11). This allows the entire table to be captured in the web snapshot, and then it is scaled down to the specified 2.25x4.00 page size. In the second print the html page size is again set to the printer default (but that's now the label size, 2.25x4.00). In this instance the table only partially fits in the available space, and gets cut off because the html table doesn't shrink far enough. The reason why it is not printed right up to the edges of the paper is because of the scaling - html page height is by default dynamic. So the more rows you add the smaller the overall scale will be to fit that height on the page and the further from the edge those cut off columns will be: |
So the dimensions are backwards? I'm not sure what the proposal here is... |
Or is this a job for a CSS rotation hack? |
Not really, and even if we do that, the default web width used will be 384 pixels, so only about half of the table would show up. (it needs a web width of at least 654 pixels to fit). And once more, any scaling for the vertical dimension would create a large whitespace on the right side of the label. The way 2.0 is set up to deal with this is to define |
Yes, 4in => 384 pixels for the webpage. Using your table, the minimum width to fit is 454 pixels (~4.75in), leading to the cut off at 4in. And then it expands to fill the 6in (576pixel) width, so that one is a full capture. Keep in mind
The left-edge issue is your printer margins. QZ is trying to print from [0,0] but your label printer cannot reach that far, so it is cut off. So that's actually separate from the capture being cut off here. |
@bberenz Ahh, now I understand how this works. I used the pixel dimensions of the HTML table and was able to get it to print properly. Would it make sense to have It's easy to tell the pixel size of a page with the browser tools. Why have developers then convert the pixel dimensions to, for example, inches? |
I don't think it would. CSS allows for physical length units, which I would hope developers use to layout HTML pages for printing, as it provides screen agnostic in/mm/cm dimensions, making this a lot easier to work with. We also use |
I'm closing this issue as |
There may be a bug with HTML sizing/scaling when the paper size set at the driver is not typical (US Letter, A4, etc). This was discovered on a Dymo label printer, but was reproducible with a PDF printer.
2.25 x 4.00in
is a label size that was installed with the Dymo driver.Steps to Reproduce
size: {width: 2.25, height: 4}
andorientation: landscape
2.25 x 4.00in
2.25 x 4.00in
Before driver size change (first print)
After driver size change (second print)
The text was updated successfully, but these errors were encountered: