128142 - [FIX]Need way to set/save the Print Command

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Mike Deibler]

Mozilla 0.9.8

The Print Command for the PostScript/default printer is lost
every time the browser is restarted.  The value it starts with is
"lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}" and there
is nothing in the preferences to set this value.  I can change
it, but all changes are lost when the browser is shut down.
This make printing bothersome as you have to change the Print
Command every time you start the browser.

Linux, RedHat (2.2.19-6.2.1 kernel)

Comment 1

[sujay]

sounds familiar..do we have a DUP on this ?

Comment 2

[Boris Zbarsky [:bzbarsky]]

gisburn, this sounds like one of yours...

Comment 3

[sujay]

I also see this problem...this is a big regression! 

Comment 4

[Roland Mainz]

We need a counterpart for InitPrintSettingsFromPrinter() - a
SavePrintSettingsFromPrinter() to get this properly working. Otherwise we lack a
centralized, general place where we save the settings, hack the code somewhere
else and risking regression all the time... ;-(

For now - as a workaround the user can do this:
1. set |pref("print.postscript.print_command", "lpr
${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}");| in prefs.js to set the print
command for all printers (note that ${MOZ_PRINTER_NAME} is the printer name (if
it is != "default")).
2. set |pref("print.postscript.printer_foobar.print_command", "lpr
${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}");| in prefs.js to set the print
command for printer "foobar" only (OK, a shorter way would be
|pref("print.postscript.printer_foobar.print_command", "lpr -P foobar"|)

Comment 5

[sujay]

can we fix this ASAP? thanks..

Comment 6

[Roland Mainz]

sujay wrote:
> can we fix this ASAP? thanks..

Sure, but please give use the neccesary time to fix it using the clean solution
(e.g. |SavePrintSettingsFromPrinter()|) this time, otherwise it will come back
again some day (sort of undead zombie bug =:-) ...

Comment 7

[rods (gone)]

This is really a problem for the UNIX folks.

Comment 8

[sujay]

can we back out the fix that caused this problem until we get a better fix?

We're gonna get flooded with DUPs on this.

Comment 9

[rods (gone)]

Attachment: patch

Inital patch

Comment 10

[Kevin McCluskey (gone)]

nsbeta1+

Comment 11

[rods (gone)]

Attachment: complete patch

This patch does the following:
1) Removes most all the unneeded data from nsPrintOptions service. All data
   should be in the PrintSettings.
2) Removed unneeded methods from PrintOptions
3) PrintOption can now read and write (most) all the data in a PrintSettings 
   object. The items not saved are those used during the printing process and
   it wouldn't make any sense to save them.
4) Adds a prefs for turning on and off the automatic saving of PrintSettings.
   If this is turned on it is almost the same as using the global PS.
5) On Linux it turns on the saving of PS prefs and turns on the global PS. 
   Meaning it will always use a single Global PS object.
6) The PrintSettings can be initialized from a generic non-printer specific 
   set of prefs. Then if a printer name is available in the PS then it tries
   to initialize itself from the printer specific prefs. This enables to define

   "back stop" prefs for picking up first. Then the printer specific prefs 
   can override those settings.
   For example, we may define in prefs that the default paper size 8.5x11, 
   then if if the "save PS prefs" is turned on, for a given printer it might
   save 8.5x16 as the size.

Comment 12

[Roland Mainz]

Comment on attachment 72610 [details] [diff] [review]
complete patch

Nice... :)

r=[e-mail]

Please file a bug to implement the Linux-specific parts for  the new features
introduced with this patch...

Comment 13

[rods (gone)]

The new feature is that I added the paperSizeName attr to nsIPrintSettings,
needed to get that in before 1.0 iface freeze

Comment 14

[Marc Attinasi]

Comment on attachment 72610 [details] [diff] [review]
complete patch

sr=attinasi (whew!)

Comment 15

[rods (gone)]

Attachment: final patch

The difference between this patch and the previous patch is that I have added a
set of "flags" for inidicating which PrintSettings attrs need to be init/saved
to prefs. These are setup and used in printdialog.js Other than that, it is
pretty much the same patch.

Comment 16

[dcone (gone)]

Comment on attachment 73863 [details] [diff] [review]
final patch

r=dcone

Comment 17

[Marc Attinasi]

Comment on attachment 73863 [details] [diff] [review]
final patch

sr=attinasi - You do not need to check for the doAll case - the bits are all
filled for kInitSaveAll so the individual bit-tests will work fine.

Comment 18

[rods (gone)]

I just made the small change, ready for a=

Comment 19

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 73863 [details] [diff] [review]
final patch

a=shaver for the 1.0 trunk, but _please_ test printing thoroughly (once through
each of those prefs) on the Big 3 before checking in.

Comment 20

[rods (gone)]

fixed

Comment 21

[rods (gone)]

really fixed

Also earlier I checked in a bug that refered to this bug but it was Bug 128427

Comment 22

[rods (gone)]

Had to back oout changes

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is breaking the Classic Mac builds on tinderbox.

Comment 24

[rods (gone)]

fixed

Comment 25

[sujay]

Mike/Roland/Boris, does this look fixed to you all ? please check it out..
try in latest build...I"ll also try...lets report back here...thanks..

Comment 26

[sujay]

I didn't hear back from anyone...can a couple of you please
help verify this? thanks!

Comment 27

[Daniel Smith]

I haven't tried any of the nightly builds, but on build 2002031312 (0.9.9) on 
all the operating systems that I've tried (Linux, NT, Win2K) the Print 
Background (colors & images) option still does not remember any values.

Comment 28

[sujay]

guys, I cannot verify this until I get some systems here configured to print on
linux...can a couple of you help verify this?

Comment 29

[sujay]

still not fixed...


I still get "lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}"
in the Print Command field in the print dialog.

it should be just "lpr"

Comment 30

[Roland Mainz]

sujay:
It works for me.
Steps to reproduct (without killing trees):
1. Open the Zilla
2. Go to the "File/Print..." menu
3. Printer should be "PostScript/default" (unless you do something special like
MOZILLA_POSTSCRIPT_PRINTER_LIST or using Xprint)
4. Go to the print job options dialog
5. Replace the command with "tail"
6. Print
7. Exit the browser
8. Open the Zilla
9. Go to the "File/Print..." menu
10. Go to the print job options dialog

Result:
"tail" should be the print command for this printer

Note that "lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}" is the _default_
for all printers to allow that Mozilla can set a specific printer name.

Example:
% export MOZILLA_POSTSCRIPT_PRINTER_LIST="foo bar"
% ./mozilla

will give you the printers "foo", "bar", "default" in the print dialog.
Mozilla will set the $MOZ_PRINTER_NAME _INTERNALLY_ to the name of the selected
printer - and the "lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}" will set
the -P option of "lpr" based on that info.

Where is your problem ?

Comment 31

[Kevin McCluskey (gone)]

Marking nsbeta1-.

Comment 32

[sujay]

ok it works..

REOPEN if anyone is still seeing a problem..

Comment 33

[sujay]

verified.