Printed content is unexpectedly rotated and clipped, when printed with thermal printer, if the print target is wider-than-it-is-tall (e.g. 2x1 labels)
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: johnmaverick74, Unassigned, NeedInfo)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: enterprise)
Attachments
(4 files)
Steps to reproduce:
I've tried to print a document
Actual results:
The page orientation setting from the print dialog as gone missing
Expected results:
The page orientation setting from the print dialog should be present
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
additional details:
on linux (neon) the bug does not exist.
However, i'm not sure if i'm running
114 candidate build1
or
114 candidate build2
I may be on build1 in neon and the bug been introduced on build2 only
(which is the one used on the windows 10 machines, that do have the bug)
Apparently, i'm on build1 in linux neon (provided by canonical)
Comment 4•3 years ago
|
||
This might be expected. If the page is specifying an orientation in their print CSS then the orientation option is hidden. It seems like our PDF viewer is setting this, so if it's a PDF then this may also be expected.
Is it gone for all pages or just some of them?
Oh, i see!
Then it's working as expected because it behaves like this in PDF's. Regular pages (most of them, at least) it's present.
Even if i still have to analise certain use cases (which in a worst-case scenario may require the opening of additional bug reports)
I believe we can safely close this one.
Thank you for your clarification :)
I'm reopening this because we need the option to overwrite the page orientation.
The PDFs preset page orientation is wrong and we need to change it so that it does print correctly.
Presently, that option is hidden.
Tests in chromium-based browsers (where we can overwrite the preset value) reveal that it does solve the problem.
so, my proposal is to show the option with the preset value selected but to allow user to overwrite it.
Workaround (for anyone that needs it): use the printer's config dialog -> every-single-time-you-print.
@Mark Striemer is there any change for reevaluating this?
Other browsers keep providing the option for the user to overide the pre-set page orientation!
This would be great for use cases where the page orientation is wrong
Comment 8•3 years ago
|
||
We're finding that in some cases, Firefox keeps changing the orientation. The preview looks landscape and the printer settings are defined to print landscape, but it prints portrait.
I think whatever was changed between 113 and 114 introduced a bug.
Comment 9•3 years ago
|
||
(In reply to Maverick from comment #6)
I'm reopening this because we need the option to overwrite the page orientation.
The PDFs preset page orientation is wrong and we need to change it so that it does print correctly.
Do you have a sample PDF that you could share, that demonstrates this issue? (Either publicly here, or privately by email to dholbert at mozilla dot com, if the PDF has content that you'd rather not share publicly.
Also, could you elaborate on what ends up "wrong"? I'm guessing that you're printing to a real printer and the content ends up either too small or clipped because we used the wrong orientation? Or is it something else?
At least in web content, we infer the landscape-vs-portrait orientation from the CSS that told us the page size. If the specified page width is longer than the height, then we force landscape orientation As in e.g. this example with 4" wide by 3" tall (which is implicitly landscape since width is greater than height):
data:text/html,<style>@page { size:4in 3in}</style>Hello
(It's conceivable that PDF.js is causing trouble by using some other mechanism to hint at the page-orientation, maybe in cases of broken PDFs like what you seem to be describing, but it's hard to be sure without having a reproducing testcase at-hand.)
(In reply to flaviobombonatti from comment #8)
We're finding that in some cases, Firefox keeps changing the orientation. The preview looks landscape and the printer settings are defined to print landscape, but it prints portrait.
This sounds like a distinct issue. I think I found one way of triggering something like you describe; I'm going to spin it off as a separate bug. Thanks!
Comment 10•3 years ago
•
|
||
(In reply to Daniel Holbert [:dholbert] from comment #9)
This sounds like a distinct issue. I think I found one way of triggering something like you describe; I'm going to spin it off as a separate bug.
(closing the loop on this: I filed bug 1839536 for the thing that I found, and @flaviobombonatti's issue from comment 8 might be thermal-printer-specific and is tracked in bug 1838989.)
| Reporter | ||
Comment 11•3 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #9)
Do you have a sample PDF that you could share, that demonstrates this issue?
Hi. Yes i do have.
I'll attach a PDF (test.pdf) and a scan of the result (label.jpg) we get in a real printer
As you can see from the scan printing comes with a 90º rotation (wrong orientation), however, in the print preview, everything was right.
Also, if i do get to the native printer dialog and set the right orientation, it does print fine.
(It's conceivable that PDF.js is causing trouble by using some other mechanism to hint at the page-orientation, maybe in cases of broken PDFs like what you seem to be describing, but it's hard to be sure without having a reproducing testcase at-hand.)
In this specific case, i used libreoffice to generate the PDF (as opposed to PDF's generated by our software). But the result was the same.
| Reporter | ||
Comment 12•3 years ago
|
||
| Reporter | ||
Comment 13•3 years ago
|
||
| Reporter | ||
Comment 14•3 years ago
|
||
All in all, if we have the page orientation option back, all will be good and well concerning this issue...
| Reporter | ||
Comment 15•3 years ago
|
||
This might be relevant...
Attached are the printer settings dialog. As you can see they have "Portrait" as landscape, and Landscape as portrait.
I'm not sure if this is a bug or intentional, but i suspect it has some kind of logic because i have upgraded drivers and software to the latest version and this settings remain as they are.
It may have some logic i'm not aware off...
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Looks like there are a number of related bugs filed that are all slightly different. Linked to bug 1793220 which includes the change that caused this behaviour change along with bug 1820651 changing our PDF.js CSS rules.
I believe the separate issues will be looked at individually (but considered together)
| Reporter | ||
Comment 17•2 years ago
|
||
Just an update about this.
We had to change printer and instead of a toshiba we now have a Brother.
I was - somehow - hopping the new printer would not have this problem.
Unfortunately, the same thing happens!
With the "new" printer we still have to go to the printer preferences and override the page orientation.
I guess this is why chromium-based browsers keep the option visible.
The lack of options is presenting a problem! Can't we just show it again?
It can't be that hard to do...
(a small rant: This has gone a bit too-far. The pile of Firefox-related issues have became too many and there's some pressure to consider alternatives at the cost of loosing privacy and undergo some difficult migration procedures...)
Comment 18•2 years ago
|
||
(In reply to Maverick from comment #17)
The lack of options is presenting a problem! Can't we just show it again?
(Per bug 1838989 comment 11 / bug 1863500 comment 5: it might not be as simple as just showing the option.)
Per bug 1838989 comment 12, I'm morphing the bug title slightly to describe the issue, and I'll use this as a duplicate target for the various bugs that seem to have been reported on the same issue. And I'll set aside some time over the next week to explore options here.
| Reporter | ||
Comment 22•2 years ago
|
||
Picking up https://bugzilla.mozilla.org/show_bug.cgi?id=1863500#c5
While i'm not 100% sure, from what i recall from my tests, i can confirm the same result with acrobat. However i do remember chromium based browsers (e.g.: edge) and, back when i originally filled this, ms edge also had the same problem.
The difference was that in ms edge the page orientation option was there and we could change it with a click in the browser's print dialog (and it would remember it!) as opposed to Firefox where the only workaround was to go to the system's print dialog for every single print to override the orientation ( which, to our frustration, here, takes "eons" to load and is aggravated by the fact that we print a lot! ).
Either showing page orientation option or not, I'm sure you'll find the best way to deal with this!
Thank you, in advance, for looking into this @dholbert :)
| Reporter | ||
Comment 23•2 years ago
|
||
@dholbert where you able to find anything on this issue?
| Reporter | ||
Comment 24•2 years ago
|
||
I don't think i can code anything this level but can i be of any help in any way to accelerate this?
Comment 25•1 year ago
|
||
Still need to circle back to this. I don't think there's any way user-wise to accelerate this. Sorry that it's sat for a while. I'm traveling for the next week, but can try to get to this soon after returning home.
One thing that might possibly help in the meantime: another user who's hitting what-I-suspect-is-this-same-issue posted their workaround in bug 223004 comment 16. (In their workaround, note that the second about:config pref is of the form print.printer_YOUR_PRINTER_NAME.print_orientation, where YOUR_PRINTER_NAME needs to use the name of your actual printer, as Firefox knows it. You can likely find the correct string to use for that by searching for about:config for print.printer, assuming you've printed to the printer before.)
Updated•1 year ago
|
| Reporter | ||
Comment 26•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #25)
Still need to circle back to this. I don't think there's any way user-wise to accelerate this. Sorry that it's sat for a while. I'm traveling for the next week, but can try to get to this soon after returning home.
One thing that might possibly help in the meantime: another user who's hitting what-I-suspect-is-this-same-issue posted their workaround in bug 223004 comment 16. (In their workaround, note that the second
about:configpref is of the formprint.printer_YOUR_PRINTER_NAME.print_orientation, where YOUR_PRINTER_NAME needs to use the name of your actual printer, as Firefox knows it. You can likely find the correct string to use for that by searching forabout:configforprint.printer, assuming you've printed to the printer before.)
I've gave it a shot, but had no luck!
Even with print.printer_YOUR_PRINTER_NAME.print_orientation set to 1 it still doesn't work as expected.
It seems firefox ignores it and prints however it thinks its the right orientation...
Please, it's a very annoying bug...
Comment 27•1 year ago
|
||
I also have this issue, printing to two thermal printers (Zebra GK420t), one set-up for 1.25x2.25" labels and the other for 2x4" labels.
Sample label document: https://drive.google.com/file/d/1_dcnCrRgz6qCrMjG7nJe6pdKfPpBFfYM/view?usp=sharing
Default output: https://drive.google.com/file/d/1v10XWa3XmDmv-RoMbSxvKRciP-cc9EI0/view?usp=sharing
Output via Print using system dialog: https://drive.google.com/file/d/1LDjiYs1f1zt5PU41e-n2UxhvaYevX9pm/view?usp=sharing
Comment 28•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #25)
Still need to circle back to this. I don't think there's any way user-wise to accelerate this. Sorry that it's sat for a while. I'm traveling for the next week, but can try to get to this soon after returning home.
One thing that might possibly help in the meantime: another user who's hitting what-I-suspect-is-this-same-issue posted their workaround in bug 223004 comment 16. (In their workaround, note that the second
about:configpref is of the formprint.printer_YOUR_PRINTER_NAME.print_orientation, where YOUR_PRINTER_NAME needs to use the name of your actual printer, as Firefox knows it. You can likely find the correct string to use for that by searching forabout:configforprint.printer, assuming you've printed to the printer before.)
This workaround does take me directly to the "Print using system dialog" and saves a great deal of time.
Comment 29•1 year ago
|
||
(In reply to Andrew WoolandPrince from comment #28)
This workaround does take me directly to the "Print using system dialog" and saves a great deal of time.
I used the "Print using system dialog" ugly workaround until now, but enabling this you run to another bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1508575
Could someone help us to prioritize these bugs? We are at a dead end if we want to use Firefox.
Updated•1 year ago
|
Comment 30•1 year ago
|
||
We have the same issue with a EPSON TM-C3500 printer and 85x54mm labels under Windows.
It looks like if firefox sees that the paper is wider than long, firefox forces the printer driver to "Landscape".
Unfortunately, the printer then rotates everything.
Firefox should not change the orientation in the printer driver.
Comment 31•11 months ago
|
||
Buf! Since last update 128.13 ESR the "Print using system dialog" (enabled via UseSystemPrintDialog policy) workaround brings more problems than solutions. Now, when you select the printer (any printer, not only thermal) and click on "Print" button, nothing happens. Browser keep blocked for some seconds and nothing happens. Result: hundreds of users keep calling because they can't print and the only alternative we can give is disable UseSystemPrintDialog and use Chrome for printing with thermal printers.
Comment 32•11 months ago
•
|
||
(In reply to Dimas from comment #31)
Buf! Since last update 128.13 ESR the "Print using system dialog" (enabled via UseSystemPrintDialog policy) workaround brings more problems than solutions. Now, when you select the printer (any printer, not only thermal) and click on "Print" button, nothing happens.
Sorry about that -- we're aware of an issue like that in 128.13 ESR (bug 1980356), which specifically happens when printing PDF files in particular, and specifically when the print is initiated by clicking the "print" icon/button at the top-right of the PDF-viewer interface. (If you're aware of other ways to trigger the issue, please let us know, ideally in a new bug report or over on bug 1980356.)
The current workaround is to use Ctrl+P (or Cmd+P on macOS) to initiate the print; or select the Print menu-item in Firefox's hamburger-menu. We're looking into the bug and will post more details on bug 1980356 when we've got a fix.
Description
•