Page orientation cannot be chosen when printing a PDF document
Categories
(Toolkit :: Printing, defect, P3)
Tracking
()
People
(Reporter: ebretscher, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0
Steps to reproduce:
Open a PDF document in a Firefox tab
Select Print to bring up the print dialog
Actual results:
The print dialog doesn't offer the option to choose the page orientation.
Opening the same document for printing in Acrobat Reader allows printing any document in Portrait/Landscape/Auto orientation.
Expected results:
The print dialog should always include page orientation options. The user can have his/her own reasons to print a document in a given orientation regardless of what the original document format.
This bug appears somewhat similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1745844, except that it seems systematic when the page is a PDF document.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•2 years ago
|
||
Reproduced the issue with Firefox 119.0 (2023-10-19) on Win 10 and macOS 12 ARM. Indeed when I open the print dialog while a PDF is opened, the page orientation is missing.
Marking issue as new for engineering input. Thank you.
|
|
||
Comment 4•2 years ago
|
||
The severity field is not set for this bug.
:calixte, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 5•1 year ago
|
||
This issue is due to the fix for bug 1820651.
In Chrome, when printing a pdf, there's no way to change the orientation but in Edge it's possible to change it (it depends of the selected printer).
I don't know what we're supposed to do exactly.
:dholbert, what do you think about this bug ?
|
||
Comment 6•1 year ago
•
|
||
Reporter: is it possible to share the PDF that you'd like to print in a non-default orientation, and/or more details about your use-case here?
You said:
The print dialog should always include page orientation options. The user can have his/her own reasons to print a document in a given
orientation regardless of what the original document format.
It's technically true that a user might have their own personal reason to want to flip the orientation, but by the same token, a user might also want to print 3 pages per sheet, or print a document scaled-up-and-translated so that only a particular part of the PDF is visible; and we don't offer UI to do those things.
For a document with a particular specified dimensions, we intentionally automatically match the dimensions to align with the output paper (modulo a few known bugs, see below) -- and we do that because that's essentially always what a user expects, to a first approximation (in the absence of special reasons that you alluded to). Not-doing-this would be particularly confusing to a user when the PDF page-size is exactly the same as the printer's page-size. (If we were to rotate and shrink a portrait/us-letter-sized page to fit onto a landscape/us-letter-sized paper, many users would be confused and upset, even if they had inadvertently ticked the option to do that.)
Having said that: there are also known cases where we get things wrong, and I wonder if you're hitting one of those cases and that's what's making you want this UI? Bug 1836028 is one such case. Ideally we'd like to fix those cases so that they "just work" rather than adding UI to flip the orientation and relying on users noticing busted printouts and needing to flip the orientation manually. But in any case, it would help to know what PDF you're trying to print and why you'd like to flip the orientation (i.e. whether we're just getting it wrong in the first place, vs. whether we're doing something reasonable and you'd like to flip the orientation for some particular special use-case.)
Sample file that is desirable to print scaled in a portrait orientation so 2 labels can be fitted on one A4 page for example.
The issue is particularly prevalent when printing PDF documents with a target paper size that differs from the physical paper size on the printer (see attachment provided). In response to your comment/question, I would also note that it is near-standard for all printing operations to be able to choose basic parameters like scaling and orientation, even though it not often necessary because the document format tends to match a common physical paper size like A4 or US Letter.
Printing multiple pages per sheet, booklets etc clearly goes one step further towards publishing and it is more acceptable to have to print the file from a more specific application like Acrobat Reader in these cases.
|
|
||
Comment 9•1 year ago
•
|
||
(In reply to Eric B. from comment #7)
Sample file that is desirable to print scaled in a portrait orientation so 2 labels can be fitted on one A4 page for example.
Gotcha. So, two questions...
(1) note that Firefox does support printing with 2 pages-per-sheet -- there's a "pages per sheet" dropdown in the "More settings" section of the print dialog. Does this address your use-case?
(If you're trying to print multiple labels from different PDFs on the same sheet, then it's perhaps a bit counterintuitive to use that option, but I think it should still achieve the desired outcome of rotating-and-scaling. And if you e.g. flip the paper over and put it back in your printer -- as I think you'd be intending to do, if you were doing this using a orientation-selector -- you'll probably get the outcome that you want, if you use "pages-per-sheet:2" for both of the print operations that you use to print onto that paper.)
(2) Firefox also offers a "Print using the system dialog" link at the bottom-right of our print dialog, and that system dialog probably offers you the ability to choose the page orientation. (It does for me at least, on Linux.) Does that work as you expect? (admittedly requiring a few extra clicks)
I would also note that it is near-standard for all printing operations to be able to choose basic parameters like scaling and orientation
That may be true, but most printing operations are working with content that's not already enforcing a particular page size, where landscape-vs-portrait wouldn't inherently affect the content-scaling.
In this case, where a browser is presented with content that has a specific mandated page size, and hence where one orientation typically involves a substantial downscale: we're trying to simplify things by choosing the orientation that's least likely to involve a downscale.
Our print dialog does make a few simplifying assumptions like this, with the intent of addressing the 99%-likely use-case, with the intent that folks who want more control can click out to the system print dialog (per (2) above) and hopefully will still be able to address their use case that way, while folks who are happy with the default can enjoy a simpler UI and reduced decision/option-paralysis.
|
Reporter | |
Comment 10•1 year ago
|
||
1/ In this case, printing 2 pages per sheet does happen to switch the orientation and it would indeed allow re-feeding the paper upside-down to print a second label from another file, which is the intent here.
2/ Using "Print using system dialog" should usually work indeed, it seems to depend on the printer driver.
Both workarounds are certainly useful, albeit not automatically obvious.
I think you are complicating the situation by trying to simplify it. There is no need to differentiate depending on whether the content does come with a specified paper size/orientation or not. Choosing the default orientation using the specification from the content when available makes sense, but enforcing it by then removing the option to change it goes too far.
Choosing paper size and orientation is something that is essentially always available and expected. I don't think there is any scope in this direction to "improve" the UI, because the UI displays a preview of the result and this makes the result obvious. It just creates problems when someone does want to change it for a good reason, whatever that is. The fact that the option sometimes exists and sometimes doesn't is inconsistent, confusing and irritating. Even Adobe Acrobat allows rotating the page to go against the document default.
Note that there is/was another bug regarding being unable to choose the paper orientation when printing some web pages, possibly because they specified an orientation. I created this bug report because it is systematic with PDFs.
|
|
||
Comment 11•1 year ago
•
|
||
(In reply to Eric B. from comment #10)
Both workarounds are certainly useful, albeit not automatically obvious.
That's good to hear.
(I can see how those options might not be obvious for your use-case, though probably most people wanting multiple pages-per-sheet are doing so when printing a multi-page document, in which case it's probably more natural to go looking for the "pages-per-sheet" UI rather than the orientation UI.)
I think you are complicating the situation by trying to simplify it. There is no need to differentiate depending on whether the content does come with a specified paper size/orientation or not. Choosing the default orientation using the specification from the content when available makes sense, but enforcing it by then removing the option to change it goes too far.
Note that we only removing the option from this "simple/easy" print dialog. As noted at the end of comment 9, the UX designer's intent here was to strike a balance between being lightweight (minimal UI & user cognitive load) while still addressing most use cases, and allowing the rarer more-complex use cases to click out to the system print dialog.
It's also not as simple as just showing the orientation selector, because it's not at all clear what it should do, or what users will expect it to do. See notes below about Safari vs. Edge (who do show portrait/landscape UI for PDFs, but they each do something completely different from each other, and different from what you're asking for it to do).
Choosing paper size and orientation is something that is essentially always available and expected.
I think you'd be surprised, actually. :) I just tested, and no browser does what you want.
Let's compare other browsers on this:
- Chromium's print dialog makes the exact same choice that we do here, hiding this option when you print a PDF. (They hide more than we do, in fact, e.g. margin settings are completely unavailable.)
- Safari's print dialog offers an orientation selector, but it's ~useless; you get the exact same printed output regardless of what you choose, at least for my printer. Changing this option just changes the rotation of the previewed sheet of paper.
- Edge's print dialog sort-of does what you want -- if you choose "orientation: landscape" then they rotate the paper while keeping the content upright (so e.g. portrait-on-landscape or vice versa). However, they appear to center the PDF on the paper in whichever dimension has free space available, which makes it entirely unsuitable for your multiple-pages-per-sheet use-case.
Note that there is/was another bug regarding being unable to choose the paper orientation when printing some web pages, possibly because they specified an orientation. I created this bug report because it is systematic with PDFs.
Right, they'd behave the same. We just render PDFs as a glorified web page with a specified page size (and a bit of additional magic behind the scenes).
(side note, I marked the attachment as private, out of an abundance of caution, since it looked like it may have had some personal contact info in it. In any case, its content doesn't matter; it just illustrated one use-case for mismatched-orientation printing, namely for "roll-your-own" multiple-documents-per-printed-sheet print layout, per comment 7.)
|
|
||
Comment 13•1 year ago
•
|
||
I'll reclassify this to our printing UI component; the folks who maintain the print dialog UI/user-experience may have additional thoughts here.
(If there's another bug on the same issue for web pages that have a specified page-size, we might want to just dupe them together.)
Fair warning on likelihood/timeliness of a fix here: given the following...
a) this desire (printing PDFs on the opposite orientation paper) is a fairly niche use-case
b) the desired-results can already be achieved using our existing UI, per beginning of comment 10 (with more or less obviousness depending on the use-case).
c) no other browser does what you expect here (per comparison in comment 11)
d) we're pretty resource-constrained in terms of both UX and engineering folks working near our printing code
...it's unlikely a fix will be forthcoming that adds the UI that you're asking for here, in a way that does what you want.
For now, your best bet might be to use the workarounds that we landed on above.
For completeness -- in addition to the browsers I mentioned in comment 11, I tested the free "Acrobat Reader DC" from the Windows 11 Store as well. They appear to center the PDF on the opposite-orientation page, like Edge does -- this makes it unsuitable for the "fitting multiple printouts on a single sheet" use-case from comment 7.
(If you dive further into their print dialog, it does have some fancier modes that would avoid this centering -- "Multiple" (i.e. N-pages-per-sheet) and "Booklet" (which is like 2-pages-per-sheet with some additional paper-stacking logic, I think). Those do seem to meet your needs, but similarly the 2-pages-per-sheet UI in Firefox would as well. Acrobat does offer more flexibility here (e.g. letting you customize the exact grid dimensions and orientation of the paper in your N-pages-per-sheet layout, for example), but that's because it's designed for a more fully-featured print-layout-suite experience, whereas Firefox and the other browsers are just trying to provide something straightforward to address the most common use-cases, with the system-print-dialog escape-hatch to address more-complex use-cases.)
|
|
Reporter | |
Comment 15•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #11)
It's also not as simple as just showing the orientation selector, because it's not at all clear what it should do, or what users will expect it to do. See notes below about Safari vs. Edge (who do show portrait/landscape UI for PDFs, but they each do something completely different from each other, and different from what you're asking for it to do).
An orientation selector should place the short edge of the paper parallel to the top of the content to be printed in "Portrait" mode, and the long edge of the paper parallel to the top of the content in "Landscape" mode. I think that this definition should reflect the normal expectations of users. Some applications mishandle the matter to various degrees, but this represents another issue.
Choosing paper size and orientation is something that is essentially always available and expected.
I think you'd be surprised, actually. :) I just tested, and no browser does what you want.
Yes, but you are restricting the field to browsers only and they are notorious for being bad at printing content. A typical user has one browser besides a broad range of other applications able to print. Now, some of those are simply able to print with either orientation through their use of the system print dialog, but not all of them, and virtually all applications allow choosing page rotation at will.
(In reply to Daniel Holbert [:dholbert] from comment #12)
I marked the attachment as private, out of an abundance of caution, since it looked like it may have had some personal contact info in it.
Thank you. It has private information in it indeed, but I had no option to make it private when I uploaded it.
(In reply to Daniel Holbert [:dholbert] from comment #13)
I'll reclassify this to our printing UI component; the folks who maintain the print dialog UI/user-experience may have additional thoughts here.
(If there's another bug on the same issue for web pages that have a specified page-size, we might want to just dupe them together.)
It sounds like a reasonable course of action. There are many bugs reported on this topic:
https://bugzilla.mozilla.org/show_bug.cgi?id=1745844
https://bugzilla.mozilla.org/show_bug.cgi?id=1555594
https://bugzilla.mozilla.org/show_bug.cgi?id=1746803
https://bugzilla.mozilla.org/show_bug.cgi?id=1653794
https://bugzilla.mozilla.org/show_bug.cgi?id=122798
https://bugzilla.mozilla.org/show_bug.cgi?id=1795253
https://bugzilla.mozilla.org/show_bug.cgi?id=1745446
(In reply to Daniel Holbert [:dholbert] from comment #14)
I am very aware of the problems with Acrobat Reader DC centering the page indeed.
Many thanks for your time and assistance with this matter.
|
|
||
Comment 16•1 year ago
•
|
||
(In reply to Eric B. from comment #15)
An orientation selector should place the short edge of the paper parallel to the top of the content to be printed in "Portrait" mode, and the long edge of the paper parallel to the top of the content in "Landscape" mode. I think that this definition should reflect the normal expectations of users.
That's one reasonable expectation for what this should do. But I can easily imagine a user expecting completely different behaviors, depending on their use case:
- Users may or may not want the rotated content to auto-center (to look cosmetically balanced, as in Edge/Acrobat-Reader).
- Users might actually want Safari's ~trivial behavior of simply rotating the paper as a whole (including the content) -- e.g. if they have a document that happens to have been scanned and saved with the "wrong" PDF page-orientation metadata, so all of the text/content looks sideways. A user may want to simply print-preview it with the text in the correct orientation, or even to print it to a save-as-PDF printer with the correct flipped orientation. The rotate-and-shrink behavior that you're proposing here would break this use-case.
- Users might print-preview a portrait-oriented document (whether PDF or HTML/CSS) where the content happens to all be squashed at the top of an otherwise-mostly-blank page; and the user might reasonably-but-mistakenly think that flipping a browser's print-orientation to landscape would make the content fit better and not-be-cropped. (Bug 1745844 comment 16 is one example of that, with an eBay order-details form.) But in fact: if the document has a specified page size (e.g. PDF, or CSS
@page {size: portrait}), then flipping the paper to landscape as you suggest would just shrink this user's broken-looking-output more, without making things any more readable/visible, and this would cause frustration/confusion.
you are restricting the field to browsers only and they are notorious for being bad at printing content.
I'm trying to compare apples-to-apples. Other applications are printing different sorts of content and have completely different UX expectations.
As one other non-browser example (on top of Acrobat Reader discussed above), I just tested LibreOffice Writer, which is what I've got handy as a document viewer/editor that deals with content-that-has-a-baked-in-specified-page-size (and has its own print dialog). I printed a portrait-oriented document on landscape-oriented paper, and LibreOffice gave me yet-another-behavior, different from any of the behaviors we've discussed so far here. :) They just print the portrait-oriented document at 100% scale, aligned to the top-left corner of the landscape-oriented paper. This means the bottom of each page gets clipped, which is extremely not-great.
Anyway -- this all isn't so much to say "hey look, other software is broken too"; my point is that this situation is extremely complex to robustly "get right"; and it's not obvious to me that any one solution here is "right"; and so the behavior we've got right now is just meant to address the common use case (auto-choosing the orientation with the best fit), and we let the system print dialog handle more complex scenarios with potentially-more-complex print configuration UI, however it wants to.
There are many bugs reported on this topic:
https://bugzilla.mozilla.org/show_bug.cgi?id=1745844
https://bugzilla.mozilla.org/show_bug.cgi?id=1555594
https://bugzilla.mozilla.org/show_bug.cgi?id=1746803
https://bugzilla.mozilla.org/show_bug.cgi?id=1653794
https://bugzilla.mozilla.org/show_bug.cgi?id=122798
https://bugzilla.mozilla.org/show_bug.cgi?id=1795253
https://bugzilla.mozilla.org/show_bug.cgi?id=1745446
Thanks. I'll look at some of those as time allows to see if we should aggregate them. (I took a quick look at bug 1745844 to get started, and in e.g. the ebay example there, a user is asking for landscape-oriented output because they want the content to be landscape-oriented -- but of course that's not what they would get if we added an orientation toggle like you're asking for here, as noted in my list of alternate user expectations above.)
|
|
Reporter | |
Comment 17•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #16)
(In reply to Eric B. from comment #15)
An orientation selector should place the short edge of the paper parallel to the top of the content to be printed in "Portrait" mode, and the long edge of the paper parallel to the top of the content in "Landscape" mode. I think that this definition should reflect the normal expectations of users.
That's one reasonable expectation for what this should do. But I can easily imagine a user expecting completely different behaviors, depending on their use case:
- Users may or may not want the rotated content to auto-center (to look cosmetically balanced, as in Edge/Acrobat-Reader).
Auto-centering is a different issue. In my view, it should either not happen, or be an explicit option, because it can make printing worthless when forced onto a smaller content sheet size, like in Acrobat Reader.
- Users might actually want Safari's ~trivial behavior of simply rotating the paper as a whole (including the content) -- e.g. if they have a document that happens to have been scanned and saved with the "wrong" PDF page-orientation metadata, so all of the text/content looks sideways. A user may want to simply print-preview it with the text in the correct orientation, or even to print it to a save-as-PDF printer with the correct flipped orientation. The rotate-and-shrink behavior that you're proposing here would break this use-case.
That is completely useless as the same page gets printed either way. Print preview is not intended for "reading" on-screen.
- Users might print-preview a portrait-oriented document (whether PDF or HTML/CSS) where the content happens to all be squashed at the top of an otherwise-mostly-blank page; and the user might reasonably-but-mistakenly think that flipping a browser's print-orientation to landscape would make the content fit better and not-be-cropped. (Bug 1745844 comment 16 is one example of that, with an eBay order-details form.) But in fact: if the document has a specified page size (e.g. PDF, or CSS
@page {size: portrait}), then flipping the paper to landscape as you suggest would just shrink this user's broken-looking-output more, without making things any more readable/visible, and this would cause frustration/confusion.
This is a mixture of page rotation and scaling. As long as print preview shows the upcoming result, the user can alter settings to achieve the desired outcome. It is logical to rotate-and-rescale as I suggested above. A user may then elect to override the automatic scale for his/her own reasons and should be able to do so.
Anyway -- this all isn't so much to say "hey look, other software is broken too"; my point is that this situation is extremely complex to robustly "get right"; and it's not obvious to me that any one solution here is "right"; and so the behavior we've got right now is just meant to address the common use case (auto-choosing the orientation with the best fit), and we let the system print dialog handle more complex scenarios with potentially-more-complex print configuration UI, however it wants to.
Any one simplistic solution isn't going to be right ever, so in my view the basic parameters required to print a document are:
1/ Page size
2/ Page orientation (as described earlier)
3/ Content scaling
4/ Number of copies
If any of those are missing, it is just not going to be generally usable or satisfactory. Any application that denies me these options is bad.
Useful, but not critical, options would be, in order:
5/ Centering
6/ Multiple pages per sheet
7/ Adjustable margins
8/ Complex layouts (booklet etc)
If we want the Firefox experience to be above the rest, then let's give users options rather than trying to take them away arbitrarily. This being said, I agree with you that the System print dialog is a valid pathway and it normally offers 1-4. Maybe it should just be much more prominent considering the number of requests related to missing features in the default application dialog.
People are asking for functionality, not complaining about too many options, and yet we are having a discussion fulled by taking features away and the supposed advantage of a UI offering almost no options. What else can I say?
|
||
Comment 18•1 year ago
|
||
@Eric, you can add my bug report opened 3 months before you, immediately when they added this "new feature" (eg removing something that no one was speaking of).
https://bugzilla.mozilla.org/show_bug.cgi?id=1852240
I'm "sur le cul" seeing all this blah blah trying to justify this restriction. My use case is also simple. Up to FF112, I was EASILY reducing parcel labels by 50% to print 2 of them on a single A4 page.
Daniel said to me "try the 2 pages per sheet". This works, yes, with an entire A4. But when I insert a half A4 because I sent two days ago a parcel, and want and can use the remaining paper instead of trashing it, bam blank page.
According to what I red here, this (removing the choice) is because print to pdf file was not ok (bug 1820651).
No matter what they say, firefox can preset the correct choice AND LET ME overwrite that choice. Again, orientation choice was available for any job up to FF112 and nobody was complaining about it.
|
|
||
Comment 19•1 year ago
|
||
"rather than adding UI to flip the orientation and relying on users noticing busted printouts and needing to flip the orientation manually. "
The UI was there since years and years. Just PRESET it to what you think is ok, NO MORE.
Description
•