Open Bug 1550887 Opened 6 months ago Updated 4 months ago

PDF printing not open preview, (preview helps user to use portrair or landscape modes)

Categories

(Firefox :: PDF Viewer, enhancement, P3)

66 Branch
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: sepocar, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

navigate to any pdf document and view it embeeded.
then, try to print it, using the printer icon in embeeded zone.

Actual results:

the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:

The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

preview options help user to adjust the correct desired orientation. just like google chrome does it. even if the pdf document pdf is showing in the page correctly, some undesired result can happen if the document is not previewed before printing occurs.

Component: Untriaged → Printing: Output
Product: Firefox → Core

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

(In reply to Sepocar from comment #0)

Actual results:
the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:
The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

Actually, File-menu|Print does the same thing and always has (it opens the print dialog, not print-preview).

The hamburger-menu (the upper right three-lines-menu) is different for some reason -- it opens Print Preview for some reason. I agree that it is confusing that these 3 different "print" options don't all do the same thing, though I don't know if there's a great way to unify them. Having said that, I suspect the Print dialog is really the right dialog to open in this case, because Print-Preview is meant to let you adjust formatting for HTML documents, and PDFs are more meant to be straight-to-printer.

Anyway, as-filed, this is a PDF Viewer bug (since that's where this print icon exists), though I don't think this behavior is likely to change.

Component: Printing: Output → PDF Viewer
Flags: needinfo?(dholbert)
Product: Core → Firefox

(In reply to Daniel Holbert [:dholbert] (reduced availability until June 12) from comment #2)

(In reply to Sepocar from comment #0)

Actual results:
the PRINTER options are opened.
( this may be not a bug, may be a feature, but it is wrong ).

Expected results:
The PREVIEW options should be opened instead, just like when we use the MENU OPTION "Print..."

Actually, File-menu|Print does the same thing and always has (it opens the print dialog, not print-preview).

The hamburger-menu (the upper right three-lines-menu) is different for some reason -- it opens Print Preview for some reason. I agree that it is confusing that these 3 different "print" options don't all do the same thing, though I don't know if there's a great way to unify them.
Having said that, I suspect the Print dialog is really the right dialog to open in this case, because Print-Preview is meant to let you adjust formatting for HTML documents, and PDFs are more meant to be straight-to-printer.

Yes, that's correct assuming that all PDF are well formatted and contain all information about the orientation ( we agree that in this case, direct printing only is the way to go ). BUT, that is not always the case, for example, many php pdf creators like laravel/dom-pdf, does not include orientation information in output pdf. or may be has to be activate one flag like in imagemagick pdf generator. anyway, my point is: there are many pdf creators that not include orientation in their output, or requires the developer (generator of the pdf) that know flags to generate a perfect pdf, and, like in html, there are many resulting flavors out there. solution: give to the end user the power to modify or apply proper format to his pdf output, if this is not done, becomes a pain, and the user has to go to chrome ( where the preview appears by default ) in order to print his inproper created pdf document.

Anyway, as-filed, this is a PDF Viewer bug (since that's where this print icon exists), though I don't think this behavior is likely to change.

Thanks for take a look.

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bdahl)
Type: defect → enhancement
Flags: needinfo?(bdahl)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.