print: RFC: Center when printing a PDF with smaller size than the output page. #13102
Conversation
I think it's safe to assume that
However it seems that Firefox-support is slightly limited, but I assume that's not a problem? |
Limited in what sense? I wasn't able to infer it from the links :) |
|
Anyhow using margins for horizontal centering should be fine too, and as I said is about the same amount of complexity. |
|
(But happy to change to flex if you think it's better, it's a matter of setting |
https://developer.mozilla.org/en-US/docs/Web/CSS/flex-direction#browser_compatibility lists Firefox as "Partial support", hence why I mentioned it. |
|
Ah:
So that was about a particular bug that has been addressed a while ago. |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/a38683271937cdc/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/a38683271937cdc/output.txt Total script time: 4.21 mins Published |
|
I think centering the page looks much better, and this also makes sense given that other viewers seem to do this as well. I also think using |
…put page. This builds on top of mozilla#13100, but this changes printing behavior intentionally so I thought it was worth discussing separately, to improve the rendering on test-cases like the one in https://bugzil.la/1697778. This matches what e.g. Evince does when you print the PDF in there on an A4 printer. We use margins to center horizontally, and flex to center vertically. The reasoning for this is that it should have better browser support (though maybe pdf.js no longer supports browsers without flex support?) and it's just as simple.
|
Thanks, updated to use flex to center horizontally too. |
emilio
force-pushed
the
print-small-page
branch
from
4afc737 to
1d70bfe
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/77f85f7ccb31972/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/77f85f7ccb31972/output.txt Total script time: 4.04 mins Published |
This improves and simplifies mozilla#13102 in order to make printing of test-cases like the one in bug 1698414 (where the real page is bigger than the target page) much better, see incoming screenshots. The reason why we need to stop setting .style.width / .style.height is to get the right auto-sizing behavior in both axes. This shouldn't change behavior as long as the print resolution is >= the CSS resolution, which seems like a reasonable assumption. If you try to print with a lower resolution than CSS, then instead of an stretched canvas, you'd get a centered CSS-quality canvas, which seems sensible. This could maybe be fixed with some CSS hackery (some combination of min / max and viewport units perhaps?), but I think it's more trouble than it's worth.
This improves and simplifies mozilla#13102 in order to make printing of test-cases like the one in bug 1698414 (where the real page is bigger than the target page) much better, see incoming screenshots. The reason why we need to stop setting .style.width / .style.height is to get the right auto-sizing behavior in both axes. This shouldn't change behavior as long as the print resolution is >= the CSS resolution, which seems like a reasonable assumption. If you try to print with a lower resolution than CSS, then instead of an stretched canvas, you'd get a centered CSS-quality canvas, which seems sensible. This could maybe be fixed with some CSS hackery (some combination of min / max and viewport units perhaps?), but I think it's more trouble than it's worth.
This improves and simplifies mozilla#13102 in order to make printing of test-cases like the one in bug 1698414 (where the real page is bigger than the target page) much better, see incoming screenshots. The reason why we need to stop setting .style.width / .style.height is to get the right auto-sizing behavior in both axes. This shouldn't change behavior as long as the print resolution is >= the CSS resolution, which seems like a reasonable assumption. If you try to print with a lower resolution than CSS, then instead of an stretched canvas, you'd get a centered CSS-quality canvas, which seems sensible. This could maybe be fixed with some CSS hackery (some combination of min / max and viewport units perhaps?), but I think it's more trouble than it's worth.
This builds on top of #13100, but this changes printing behavior intentionally
so I thought it was worth discussing separately, to improve the rendering on
test-cases like the one in https://bugzil.la/1697778.
This matches what e.g. Evince does when you print the PDF in there on an A4
printer.
We use margins to center horizontally, and flex to center vertically. The
reasoning for this is that it should have better browser support (though maybe
pdf.js no longer supports browsers without flex support?) and it's just as
simple.