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 |
|
Using the pageWidth and pageHeight definitions, the content still gets cut off. If I use pageWidth: 4 and pageHeight: 2.25, I only get six of the columns to print. The 'left' edge of the html gets cut off, too. If I use pageWidth: 6 and pageHeight: 2.25, I get all seven columns, but I still have to add a margin to the 'bottom' of the job to get the 'left (bottom)' edge to print on the label. |
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.00inis a label size that was installed with the Dymo driver.Steps to Reproduce
size: {width: 2.25, height: 4}andorientation: landscape2.25 x 4.00in2.25 x 4.00inBefore driver size change (first print)
After driver size change (second print)
The text was updated successfully, but these errors were encountered: