Open Bug 428539 Opened 17 years ago Updated 3 years ago

[UX] Neither Page Setup nor Print Preview can select the printer or its setting for page size

Categories

(Core :: Print Preview, defect)

x86
Windows XP
defect

Tracking

()

People

(Reporter: pierce, Unassigned)

References

Details

(Keywords: uiwanted)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 The only way currently to select a printer, or paper size, or other printer specific option, is to actually print a page. There should be a print preferences dialog on both the Page Setup and the Print Preview dialogs. The /only/ way to change the printer settings is to actually print a page. Example, my current configuration, has both a B&W laser printer, and a color inkjet printer. Firefox last printed on the inkjet, using a special paper size (custom 5.5 x 8.5"). I wanted to print preview a page but it still thinks its got small paper and there's no way to change this. Reproducible: Always Steps to Reproduce: 1. select page setup or print preview 2. try and change paper size? oops, can't! 3. sit there frustrated, open another beer.
Confirming for Firefox 3.0.5. (Obviously bugs need to be confirmed before someone takes them serious.)
iirc it's not necessary to print a page, but it is necessary to bring up a print menu with a printer selected, before picking a paper size. I'm not sure they would change this behavior, because most or all of firefox assumes you have a printer defined. but someone else needs to make the call on this.
Severity: normal → minor
Component: Menus → Print Preview
Product: Firefox → Core
QA Contact: menus → printing
Summary: Neither Page Setup nor Print Preview can select the printer or its settings → Neither Page Setup nor Print Preview can select the printer or its setting for page size
The problem is not to have one printer defined at all, but if you have several different printers defined and want to switch printers in relation to the page content you want to print, e.g. if you prefer to print some sites on an A4 printer, some on an A3 printer, and some on a PDF printer...
Confirming still for Firefox 3.6.3.
"There should be a print preferences dialog on both the Page Setup and the Print Preview dialogs." from Description Print preferences is printer-specific and therefore, by definition, defined in the printer driver settings registry ... for each printer registered and installed. In your case, even if there was a PPref button on the PSetup or PPreview windows, it could only refer to the last printer used and therefore it would default to your inkjet; which FF is already doing. Perhaps you meant to suggest there be a Printer Selection select list on the PSetup and PPreview pages. Then you could select a printer then close the dialogue and the printer defaults for the newly selected printer could then read by FF and applied to the current process. Keep in mind that paper size, etc. are NOT selected by FF; they are selected by the printer driver currently in use. All FF does is keep track of desired print orientation, scale factor to be used in calculating the page appearance, whether or not FF is supposed to include the background elements, the margins you would like, and the header / footer text. NONE of that is paper-size dependent. At print time, FF applies those settings to whatever paper size the printer driver supplied to it. Whether the paper size reported was proper or not is another question! I've read here and there about FF Preview's failure to account for metric-sized paper. In one case, when I reviewed the actual printer in use, I found that that printer driver didn't support the desired paper size. There is NOTHING FF can do about that. FF can only work with paper sizes the printer driver is capable of properly reporting to FF. I suspect there may also be a few printer drivers that claim to support metric-sized paper but don't properly report the actual size back to the application (eg, FF); and once again, the only recourse is to get the printer manufacturer to fix the issue. Long story short: the addition of a Printer Selection select list to the PSetup and PPreview pages might very well solve our issue. And it might not be too hard to accomplish since 99% of the logic is already in place and it would be fairly easy to test. I think this would also correct the situation Wayne encounters since FF should re-load all of the printer's data after a new printer is selected.
pretty much every other program, on MS Windows at least, that has a page setup and/or print preview dialog lets you select the printer and optionally invoke its preferences/properties dialog, then adapts to this when it returns. this is all I was asking for 2 years ago.
P.S. Anyone with Microsoft Office can see this in action. Open Word. Open the File / Print dialogue. Change printers and you will see the CANCEL button change to a CLOSE button. If you click on CLOSE instead of OK, the print dialogue window will close without printing anything AND Word will use the newly selected printer in it's deliberations thereafter. SO perhaps the solution to our issue is as simple as modifying the call to the Windows Print Dialogue and re-reading the selected printer's defaults when the dialogue is closed. And all that logic is already in place in FF (or it couldn't print!). Just a thought.
@John: sorry, I was typing same time apparently ... but great minds same channels, eh? :-)
@John: Also, Microsoft Word and Excel are the only two windows programs I know of that change the Cancel button to a Close button (ie, keeping the new settings without printing a page) on the Print Dialogue. Have you encountered other programs that do this? Just curious. I've always suspected they could do this because they know where the 'secret switch' was. ;-)
right on
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'd skip that cancel-close nonsense, its a little too over the top. just having a printer selector box with a properties button next to it, on both the page setup and print preview would be a HUGE win. page setup could get away with just having a Printer... button that itself had the selector and properties buttons if its too hard to squeeze it all in. and, yeah, i dunno how all this would translate on unix/linux implementations.
I would mark this bug for uiwanted in the keyword section of this bug. That way the UX team can find it.
Keywords: uiwanted
done, 'uiwanted' added.
In any event, it seems like this would not be hard to do ergo it should be in the next release, eh? Be bold. Go for the best fix, the intuitive fix ... not a techie fix ... remember your audience. All I can say is read carefully the above to make sure all nuances are covered or you'll suffer the slings and arrows like poor Bug 154892 has all these long years! ;-) Alas, poor Bug 154892. We know him well. :-) P.S. @John: Cancel-Close might seem a little over the top BUT it already exists AND is in use by MILLIONS of Microsoft users all over the world. Hmmm. I'm no M$ fanboy but I don't spit into the wind either. Just something to think about momentarily. :-)
The most convenient solution would be to 1a) add a "Select printer" dialog into the "Page Setup" dialog - like Opera has the button "Paper and Orientation" 1b) add a separate "Printer setup" entry to the "File" menu - like OpenOffice provides it and 2) add a "Page setup" button to the "Print preview" window - like Apple Safari provides it Each Operating System should provide such default dialogs, as far as I remember (e.g. Delphi 7 provides access to the Page Setup dialog via its wrapper "TPageSetupDlg" in the unit "CommDlg").
If 'Page Setup' just showed the page sizes available (which it will know having read the default settings for the currently selected printer), then one could verify / select the desired page size. In that way, all the printer selection and setup is done from one dialogue, the Printer Setup; keeping it simple and succinct (KISS).
I vote for this bug. the same behavior happens in seamonkey
Surprised this one is still around. My suggestion in comments 5 and 7 (and the P.S. on comment 14) would solve the problem succinctly and easily since FF is already accessing that Windows function in the first place. All that is required is to modify the existing call to the Windows Print Dialogue Box so the exit button changes from CANCEL to CLOSE upon a printer selection change. We already know this can be done since it does for at least two other very common programs we know of! As for non-Windows versions of FF, I've long maintained that the entire industry would be well-served to emulate Microsoft in this particular case and create an open-source printer interface similar to the Windows Print ... Box series (presumably using the same call parameters to make life easier for programmers who support both Windows and non-Windows applications). The non-Windows community really just shoots itself in the foot when it requires each and every different OS to re-invent the wheel on this most common aspect of computer usage. Just for reference, a few links from Google: Microsoft's overview of their Print Dialogue Box: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646964(v=vs.85).aspx Some ideas from FunctionX: http://www.functionx.com/vcsharp2008/controls/dlgprint.htm Google's take on the Print Dialogue Box (note the expanded selection of features): http://support.google.com/sketchup/bin/answer.py?hl=en&answer=114459 A really wild and totally non-standard print interface for the tech elite. I would love to observe the casual user's face upon opening this beast! LoL: http://www.imageno.com/zq32g9xutr6hpic.html P.S. Paper selection. That is done from the Properties button next to the printer selection box. FF takes the settings from it's Page Setup and reads the appropriate data from the selected printer (from the Print Dialogue Box) and (re-)creates the Preview page. Since I've been away from actual coding for way too long to offer any further assistance I'll go away now and let the experts duke this out. LoL
2016 and the print preview dialogue (both FF and TB) is still unable to neither offer nor react on-the-fly to printer/page size selection. This makes printing real trial and error when trying to change paper size and see how the actual printout fits it. Please, someone at UI dev, please, take a look at basic Chrome print page preview and see how many options they offer and how the preview reacts accordingly.
Windows 7 Ultimate SP1 SeaMonkey 2.40 HP LaserJet 200 color M251nw I do not know if SeaMonkey and Firefox use the same Print components. Also, I do not know if the driver for my particular printer provides capabilities not available for other printers. However, I just now observed the following: * If I select Print Preview and then the Print button on the on the preview window, I get a Print popup dialogue. This allows me to select the printer. The dialogue also has a Properties button that allows me to configure for paper size, paper type (e.g., envelope, card stock, gummed labels), and color. That is, I can select a printer and paper size from the Print Preview window. * If I select Print Preview and then the Page Setup button, there is no print capability. This is also true if I select [File > Page Setup] on the menu bar.
The point of this report is: You may be able to select the print setup; but you cannot preview it before printing, only after you already printed at least one page.
Summary: Neither Page Setup nor Print Preview can select the printer or its setting for page size → [UX] Neither Page Setup nor Print Preview can select the printer or its setting for page size
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.