134914 - [ps] Printing to a PostScript printer under Linux always sends output to queue "lp"

Status: VERIFIED DUPLICATE of bug 161634

(Core :: Printing: Output, defect)

Description

[Graham]

Per discussion in bug 123270 ... here is what I tried, and the results.

# export MOZILLA_POSTSCRIPT_PRINTER_LIST="esc400 lp"
# export NSPR_LOG_MODULES=nsPostScriptObj:5
# /usr/local/mozilla/mozilla

At this point Mozilla loaded my start page, which is "http://www.google.ca/".
I clicked File | Print. The dialog correctly showed "PostScript/esc400" as the
current selection, and the first item in the drop-down.

The Properties dialog for this printer shows the print command as:
  lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}

I then clicked Print to send the print job. Some debug info was sent to the
Konsole from which I launched Mozilla:

1024[8087eb0]: nsPostScriptObj::nsPostScriptObj()
1024[8087eb0]: dpi 72 top 18 bottom 18 left 18 right 18
 NO FONT WAS FOUND
 NO FONT WAS FOUND
 NO FONT WAS FOUND
 NO FONT WAS FOUND
 NO FONT WAS FOUND
1024[8087eb0]: nsPostScriptObj::end_document()
1024[8087eb0]: piping job to 'lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}'
1024[8087eb0]: piping done, copied 193884 bytes.
1024[8087eb0]: nsPostScriptObj::~nsPostScriptObj()
1024[8087eb0]: nsPostScriptObj::~nsPostScriptObj(): printing done.

At this point, running "lpq -a" shows that the job has been sent to the "lp"
queue, not the "esc400" queue.

As a temporary workaround to this problem, I tell Mozilla to print to a file, then:

lpr -Pesc400 mozilla.ps

This works but is an annoyance. 

Expected behaviour: Mozilla should print to the queue I selected :-)

Comment 1

[Roland Mainz]

Which OS do you use ? Do you use any special shell ?

Comment 2

[Graham]

Debian "woody".

Nothing strange about my shell -- it's just plain old bash.

Comment 3

[Kai Lahmann (is there, where MNG is)]

reporter: can you reproduce this bug with a recent build of mozilla (for
example, 1.1beta)? if so, please comment again with details. if not, please
resolve this bug as WORKSFORME. thanks.

Comment 4

[Graham]

That could be tricky to do, as I've dumped lpr/lpd in favour of a client-server
CUPS setup. So now the default printer according to "lpr" (which is not really
lpr, but part of CUPS) is the *only* printer.

I suppose I could set up a couple of bogus print queues at the server, make sure
I can send output to them directly from the command line here, and then see if
Moz will send output to them.

Updating Mozilla would be no trouble. I think I'm on 1.1b right now.

I've also upgraded to debian "sid" since the last time I posted here.

Honestly, I've made enough config changes between then and now that I'm not sure
I'll be able to reproduce it again. But I will try later today.

Comment 5

[Graham]

I'd forgotten that I already do have a second queue set up on the server... it's
a raw queue that I use for Windoze clients.

First, I'm going to power down the printer so that jobs don't just fly through;
they'll sit in queues and I will be able to see them. :-)

At the commandline:

lpr myfile.txt

results in the job being sent to the "esc400_ps" queue, which is the default.
This is why Mozilla works for me right now; I just pick "PostScript/default"...

anyway. The other queue can be printed to via the lpr command also:

lpr -Pesc400_raw myfile.txt 

I've verified this from the commandline; it works.

Now, to retry the tests:

# export MOZILLA_POSTSCRIPT_PRINTER_LIST="esc400_ps esc400_raw"
# export NSPR_LOG_MODULES=nsPostScriptObj:5
# /usr/local/mozilla/mozilla

Mozilla loads my start page, currently "http://www.mozilla.org/start/".
I click File | Print. The printer list correctly shows:
PostScript/esc400_ps
PostScript/esc400_raw
PostScript/default

I pick PostScript/esc400_raw and check the Properties. The print command is:
  lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}

I close the Properties dialog and click Print.

At the Konsole, I see:

1024[80882d8]: nsPostScriptObj::nsPostScriptObj()
1024[80882d8]: dpi 72 top 18 bottom 18 left 18 right 18
1024[80882d8]: nsPostScriptObj::end_document()
1024[80882d8]: piping job to 'lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}'
1024[80882d8]: piping done, copied 286887 bytes.
1024[80882d8]: nsPostScriptObj::~nsPostScriptObj()
1024[80882d8]: nsPostScriptObj::~nsPostScriptObj(): printing done.

Now pointing my web browser at my print server:

http://192.168.1.3:631/printers/esc400_raw -- no jobs
http://192.168.1.3:631/printers/esc400_ps -- Mozilla's output is here

I'm running Moz 1.1b and the output still goes to the wrong queue. Sorry guys,
this bug still exists. Please let me know if there's anything more that I can do
to help.

Comment 6

[Kai Lahmann (is there, where MNG is)]

so it always selects the first printer?

Comment 7

[Graham]

I would actually rather describe it as "always sends output to the default
printer" (since that isn't always "lp").

Comment 8

[Kai Lahmann (is there, where MNG is)]

as I can't find a dup..

Comment 9

[robert somerville]

I have same problems with 1.1b on Solaris 2.7, up to my builds of aug 29

Comment 10

[Roland Mainz]

I fixed this issue in bug 161634 ("[ps] envvar should not be freed after
PR_SetEnv") ...

*** This bug has been marked as a duplicate of 161634 ***

Comment 11

[sujay]

verified.