Closed Bug 83750 Opened 23 years ago Closed 22 years ago

Print settings are saved at shutdown but not read at next start

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3alpha

People

(Reporter: kazhik, Assigned: rods)

References

Details

Print settings aren't saved. (1) Open print dialog and change default settings. (2) Hit Print button. (3) Open print dialog again. Expected result: Dialog shows the previous settings. Actual result: Dialog shows default settings.
I dont believe we plan on saving our settings. Print settings can vary so much depending on the page.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
verified.
Status: RESOLVED → VERIFIED
*** Bug 87506 has been marked as a duplicate of this bug. ***
*** Bug 91819 has been marked as a duplicate of this bug. ***
It is true that the printer settings depend havily on the page, but the chance that if I print A4 one I want to use it always is very high. (If you change the default from "Letter" to "A4" we can close it as invalid ;-) The same is true with the printing command under Unix. If I want to use -Php5 I use it. (I have already printed hundreds of pages to "lpr" which is here a dummy printer) This may be less important under Windows since there you can setup defaults in the printerdriver, but for Unix this is important! (Unless you support CUPS...) For the other settings: Colour/grey, file/printer etc. the settings are less important.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
*** Bug 92498 has been marked as a duplicate of this bug. ***
Netscape 4.x does this properly. Added 4xp keyword. > This may be less important under Windows since there you can setup defaults in > the printerdriver, but for Unix this is important! (Unless you support CUPS...) No this is important on Windows, and is frequently used. Often you need to print several pages with the same settings (e.g., landscape v. portrait orientation, 2 pages per sheet, duplex) and it is extremely inconvenient to keep changing the printer settings for each print command. This is a bad printing usability bug. If I have to print several documents, I sometimes resort to Netscape 4.x. Also if you change the global settings in the printer driver, it will affect all other applications. The A4 setting is probably a setting that should be global, but not the ones I mentioned above. Also, I don't think bug 91819 is a dup. Although it describes a similar problem on Linux, my guess is the implementation will be different per platform and this bug which seems to be for Windows.
Keywords: 4xp
Also on Linux (2.4) Moz Build 2001081514. To clarify: The settings do stay the same until you quit and restart, but are not persisted between sessions.
*** Bug 99346 has been marked as a duplicate of this bug. ***
*** Bug 99683 has been marked as a duplicate of this bug. ***
More on default settings : on Win32 it includes the printer to use : - click print button - change the printer from windows default to another printer - OK to print - reclick print button - the printer selected is once again the windows default printer So you have to change the printer everytime you have to print a page. Netscape 4.x behaviour was to keep the printer selected in the same session.Most Win32 apps do exactly the same.
*** Bug 105649 has been marked as a duplicate of this bug. ***
Assignee: dcone → rods
Status: REOPENED → NEW
Reassigning to Rod.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
*** Bug 110747 has been marked as a duplicate of this bug. ***
*** Bug 111581 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla1.1
*** Bug 117435 has been marked as a duplicate of this bug. ***
Now my print dialog has started coming up with things like MOZ_PRINTER_NAME in it. What's that? Probably some environment variable that I don't want to mess with, but even if I could, a non-technical user sure doesn't want to see this. I've recently installed KDE 2.2.2 on my system and discovered kprinter. I don't think I want to use lpr any more even, but until this bug is fixed I have to go to properties every time and overwrite the lpr command with kprinter.
Eric Vaandering wrote: > Now my print dialog has started coming up with things like MOZ_PRINTER_NAME in > it. What's that? Probably some environment variable that I don't want to mess > with, but even if I could, a non-technical user sure doesn't want to see this. MOZ_PRINTER_NAME is used for passing the current selected printer name to the "lpr" command. Just fill the MOZILLA_PRINTER_LIST env var with your printer names and you can select it from the print dialog. Example: % export MOZILLA_PRINTER_LIST="printer1 hplaser004 myprinter9" should give you the printers "printer", "hplaser004", myprinter9" and "Default" ...
Which means I have to edit the shell script that starts mozilla (since I launch from a WM) for each release of mozilla. IMO, this is nuts. These should be in preferences, not environment variables.
Eric Vaandering wrote: > Which means I have to edit the shell script that starts mozilla (since I > launch from a WM) for each release of mozilla. No, see below... > IMO, this is nuts. These should > be in preferences, not environment variables. The "print.printer_list" is for this task (the content of the MOZILLA_PRINTER_LIST env var override this). Or use the Xprint module - it manages all that automagically (but you have to start the Xprt server at system boot or later and set the XPSERVERLIST env var to tell the applications that Xprint is available on the system) ...
Thanks. Three more questions: 1) Is there a bug for UI manipulation of print.printer_list or should I file one. 2) Is there a way to have some printers be "lpr" but also set up gv as a "printer?" 3) Why wasn't this change to the print dialog covered in the What's new section of the 0.9.7 release notes?
Eric Vaandering wrote: > 1) Is there a bug for UI manipulation of print.printer_list or should I file > one. No bug yet, please file one and CC: me (I am not a XUL/prefs expert, don't assign it to me... :) > 2) Is there a way to have some printers be "lpr" but also set up gv as a > "printer?" Oh, well... thaht's another (unwritten) bug. Please file a bug with the title "Need per printer name print commands for PostScript module", assign it to me and CC: rods@netscape.com Technically it's easy - but it forgot to file the bug... ;-( > 3) Why wasn't this change to the print dialog covered in the What's new > section of the 0.9.7 release notes? Gah! xx@@@!!xx No clue. I wrote emails, added comments to the bugs and made a status report (http://www.mozilla.org/status/2001-11-29.html) ... looks noone cared about that... ;-(
While we're on this one, I would sure like to know a way to tell Mozilla that my printer is A4 (I don't think I've seen a "Letter" printer in my life!). Seems I need to tell it every time I want to print something. This is much more annoying now, because I have to explicitly go into an extra dialog to remind it.
*** Bug 118336 has been marked as a duplicate of this bug. ***
*** Bug 118777 has been marked as a duplicate of this bug. ***
*** Bug 115208 has been marked as a duplicate of this bug. ***
I'm seeing this too in Windows 2000 with build 2002011403. Shouldn't it be at least picking up the printing preferences set as default on the computer for this printer as a starting point? I have the printer as default set to use A4 yet when you go into the printer properties within mozilla the default setting is Letter. This is really two issues: 1) Picking up computer's default settings for the printer. 2) Remembering any setting changes for the current mozilla session. As to whether you want mozilla to remember printer settings between sessions will divide people I'm sure, I can see advantages and disadvantages. The main disadvantages are for people who have roaming profiles and have different printers depending on which computer they sit at.
Strange, my mozilla 0.9.7-5 (Linux) seems to remember printer setting during a session but not after a browser restart. So I always have to switch from 'Color' to 'Grayscale' and 'Letter' to 'A4' -- this sucks! Some way of persistently storing these settings would be greatly appreciated!
I have an idea how to solve this issue (load/save "per printer" settings)... need to discuss this with rods...
*** Bug 123022 has been marked as a duplicate of this bug. ***
*** Bug 123012 has been marked as a duplicate of this bug. ***
This bug seems to be about having the settings stay "current" while the brwsoer is running but not from one invaction of the browser to the next. The issue of the selected printer being saved is fixed with bug 123335. I am marking this works for me, because the setting are now remembered. I am not sure we really want to remember them from the last time we started the browser.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Anyway, that should then be discussed in a new bug.
Okay, admittedly this bug was *originally* about print settings not staying current. But many complaints aim at persistent storage of these settings. This might seem questionable for U.S. users but most of us in Europe haven't even seen a Legal paper sheet in our lives. So for us there's a pretty good reason for Mozilla to persistently remember print settings accross sessions. Furthermore, I'm fed up with telling Mozilla each and every time, that I don't have a color printer! --> New Bug?!?
New bug! When you have filed it, please post the bug number here.
Logged bug 123554 on not picking up default printer settings from OS.
Should I be seeing the fix in the latest Netscape commercial builds. I'm running on Win95: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.98+) Gecko/20020204 Netscape 6/6.2.1+ and no printer settings are being saved. I tried - selecting a different printer - changing from 1-up to 2-up (# of pages printed on 1 sheet of paper) In both cases, when I tried to print the same page again, the settings had resorted to the previous values. Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocks: 125824
This is now fixed. It won't remember the 1up or 2up because we don't support that. But it does remember which printer you selected, the paper size, the orientation, the copies and the scaling.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
worked for me up until 0.9.9 -- now I got it broken :-( I was opening and closing a few windows (but not mozilla itself), changing print settings here and there and finally ended up with default print settings again. Seems like print settings are somehow not globally bound to the process but rather to child branches. Even if this was intended, it doesn't seem very usefull to me!
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Please close this bug. This is how it works: On all non-Mac platforms, each browser window has it's own set of prefs. On Linux, the settings in the "Properties" dialog are shared between all the browser windows. If you would like all browse windows to share the same prefs you need to change the print.use_global_printsettings prefs, set it to true. I think this should be an exposed pref in the Prefs Dialog (I see what I can do)
resolving per Rod's comments.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
Build 0.9.9 seems to use the printers defaultpapersize but only when printing from a browserwindow. When printing a mail pagesize still is letter every time. win2k, english + danish multilanguagepack
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Just wondering: Do we call InitPrintSettingsFromPrinter() when we print from MailNews ?
*** Bug 137731 has been marked as a duplicate of this bug. ***
*** Bug 137896 has been marked as a duplicate of this bug. ***
Is comment #18 supposed to be working on Linux already? I put the env variable MOZILLA_PRINTER_LIST, but when I pull up the Print properties I still get lpr ${MOZ_PRINTER_NAME:+'-P'}.
One other thing, bug #137896 which I just posted for Linux platform got marked as a duplicate of this one, but I think it's a little more than that. I'm trying to understand why we are given the opportunity to change the print margins and locations of the URL/title and scale, only to have them default to the original after the browser session is closed. It's hard to imagine when I would want the URL on the left for only one session, for instance. These seem to be user preferences to be set and remembered. Not the orientation, but the others such as scale, margins, headers/footers location. Especially Scale and margins because not all printers behave as expected. If they can't be persistent via the Page Setup, can we at least have them as things we can manually enter into prefs.js that will override the defaults (and not get blown away)? Is this reasonable? Thanks, John Cirillo
*** Bug 138388 has been marked as a duplicate of this bug. ***
*** Bug 137472 has been marked as a duplicate of this bug. ***
I agree with John Cirillo comments, IMHO all printing settings should be saved between sessions, or at least some way for changing the defaults should be available to the user, should we open a new bug or is this covered here? (I'm specially interested in changing the defaults for the headers(URL, date, page, etc.), if some one knows of some hack to remove all them by default it would be very appreciated, we need to print certain documents at my company that shouldn't have any header, and it's a pain to change the settings every time...) Thanks and best wishes \\Uriel
*** Bug 143924 has been marked as a duplicate of this bug. ***
*** Bug 144759 has been marked as a duplicate of this bug. ***
*** Bug 146339 has been marked as a duplicate of this bug. ***
*** Bug 146334 has been marked as a duplicate of this bug. ***
*** Bug 146792 has been marked as a duplicate of this bug. ***
We have a few applications developed in-house that are php-apache on the backend and (ideally) mozilla on the front. The saving of printing preferences (header/footer) is the primary thing holding back our application from being seamless/invisible to our users. It's an important issue for us regarding mozilla.
*** Bug 147025 has been marked as a duplicate of this bug. ***
Mozilla RC3. I thought I'd check out why the Headers & Footers continue to not be saved (I was sure someone would have reported the bug) and discover that this is supposed to be Mozilla policy!?! By default Mozilla truncates long URLs. URLs that are vitally important for anyone performing research or archiving documents. Well the workaround is to make the URL a header all by itself so truncation doesn't occur. Except that every time Mozilla is closed the Header and Footer settings are lost. And I have to remember to manually alter them every time. I can think of no overriding reason why anyone would want to continually lose their page setup and print settings. Please reconsider this policy. You have had lots of duplicate bug reports about this issue and will continue to do so because people just don't expect that this behaviour is intended. Thanks for all your fantastic work. Regards, Adam Warner
*** Bug 135045 has been marked as a duplicate of this bug. ***
*** Bug 158831 has been marked as a duplicate of this bug. ***
*** Bug 163364 has been marked as a duplicate of this bug. ***
*** Bug 165923 has been marked as a duplicate of this bug. ***
*** Bug 166156 has been marked as a duplicate of this bug. ***
OK, here is the current status (Solaris 2.7/SPARC+Linux): 1. Print settings are preserved between print jobs 2. Print settings _are_ saved at shutdown 3. Print settings are not loaded at next startup, you'll get the printer's defaults again...
Summary: Print settings aren't saved → Print settings are saved at shutdown but not read at next start
Raw guesing - is |initPrintSettingsFromPrefs| broken ?
I believe this is because it's saving or reading from the wrong pref name. Mozilla is saving as (for example): print.printer_PostScript/default.print_paper_name But reading as: print.postscript.paper_size This is from my experience and I don't know which one is the right one. Feel free to test it though. Just put (for eg): user_pref("print.postscript.paper_size", "A4"); In your user.js file and see if mozilla picks it up on startup. (I could, ofcourse, be completely wrong in all this but it's what I've noticed and it appears relevant :)
bug 166217 ("Print settings on Linux are saved at shutdown but not read at next start") should fix this issue for Linux/Unix and OS/2 ...
Hogarth wrote: > I believe this is because it's saving or reading from the wrong pref name. > > Mozilla is saving as (for example): > > print.printer_PostScript/default.print_paper_name > > But reading as: > > print.postscript.paper_size ^^^^^^^^^^^^ ?! Where did you get this string from ? 1. Printer names always have the prefix "printer_" to avoid that normal pref names can interfer with printer names. 2. "paper_size" is _OBSOLETE_. Please don't use it. We are now using "print_paper_name" to avoid that we may pick up the wrong paper when two papers have the same size but a different meaning for the printer and to store a tray name within this string if there is one (e.g. paper name "bottom/iso-a4" would select the tray "bottom" using the paper size "iso-a4").
Well... it's the only thing that appears to make the right paper size stick for me. I've put myself on the Cc list of bug 166217 so that I can see when it lands in the trunk and then test moz for myself without this pref.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Depends on: 166217
Blocks: 118563
Target Milestone: mozilla1.2beta → mozilla1.3alpha
*** Bug 177806 has been marked as a duplicate of this bug. ***
*** Bug 175262 has been marked as a duplicate of this bug. ***
Blocks: 135442
No longer blocks: 135442
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
*** Bug 181480 has been marked as a duplicate of this bug. ***
WFM now. verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.