136146 - [ps] Cannot set multiple printers in dropdown printer dialog box

Status: VERIFIED DUPLICATE of bug 161634

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

Description

[ktaylor]

Under "Print", I'm presented only with Postscript/default as the printer. I
don't see any way to have multiple printers (or have mozilla just look at the
/etc/printcap file and determine available printers);.

It's cumbersome to have to edit the properties for the printer and change the
command line for each printer I want to print to.

Comment 1

[Roland Mainz]

There are three ways to get more than the "default" printer in your print dialog
1. Use Xprint module (get
http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_005.tar.gz
and read the docs) [recommended for larger setups or if you want to print
non-iso-8859-1 pages]
2. Set the "print.printer_list" prefs in prefs.js to a whitespace-seperated list
of printer names you want to see in the print dialog (you have to do this for
each user account)
3. Same as [2] but set the MOZILLA_POSTSCRIPT_PRINTER_LIST env var before
starting the Zilla

RFE to support /etc/printcap is bug 135695 - however I do not see how this helps
because there is no common print system standard across Unix/Linux except Xprint
(which is item [1] above :) ...

Comment 2

[ktaylor]

Installing 3rd party software just for printing ability is probably not the best
solution.

Item #2/3 work ok....except that for the release of moz0.9.9 I had to also set
user_pref("print.postscript.printer_las4.print_command", "lpr -Plas4");

...mainly because the default lpr ${MOZ_PRINTER_NAME + '-P'}......part just
wasn't working.

lpr has been a UNIX standard for several years, and just about all unix/linux
distributions should have that capability by default, so the /etc/printcap
should not pose a problem for anyone. It's much more standard than
Xprint....which I've honestly never heard of until I started investigating this
problem.

Comment 3

[Roland Mainz]

ktaylor wrote:
> Installing 3rd party software just for printing ability is probably not the 
> best solution.

Xprint isn't 3rd-party - it comes with your X11 distribution.
However the Xprt (X print server) in Xfree86 is broken and therefore I created
an own build to work around the issues/bugs in it...
Solaris and HP-UX are shipping with working versions of Xprt - you may use it if
you have such a box (Xprint is network-transparent - you only have to setup one
server for all clients).

> Item #2/3 work ok....except that for the release of moz0.9.9 I had to also set
> user_pref("print.postscript.printer_las4.print_command", "lpr -Plas4");

Uhm... this should be
|user_pref("print.postscript.printer_PostScript/las4.print_command", "lpr
-Plas4");| (AFAIK)

> ...mainly because the default lpr ${MOZ_PRINTER_NAME + '-P'}......part just
> wasn't working.

Can you provide any debugging output ("truss"/"strace" etc.) to see how "lpr" is
started) ?
[just wondering: How old is your build ? Can you try a nightly from
http://ftp.mozilla.org/pub/mozilla/nightly/latest/ and check whether the problem
still exists ?]

> lpr has been a UNIX standard for several years, and just about all unix/linux
> distributions should have that capability by default, so the /etc/printcap
> should not pose a problem for anyone.

Well, there is no /etc/printcap on Solaris (and the print system differs from
Solaris version to version), HP-UX, AIX and other Unix-variants ... and even if
it is present there are syntax variants in these files which makes it hard to
write a one-for-all parser which would work on all platforms (and to make it
really "fun": Some Linux versions ship with /etc/printcap but never use it).
Using the "lpc"/"lpstat"/"lpget" commands to query the printers is not an option
either because it can take minutes to lookup all printers in some
configurations...

> It's much more standard than
> Xprint... which I've honestly never heard of until I started investigating 
> this problem.

Xprint is the X11 print system, part of X11R6.4 and above (for example
Motif/CDE2.x uses it as it's main print system) ...

Comment 4

[ktaylor]

The printers are working with the the user pref I have, but I'll make that
change to the line you mentioned.

The latest 0.9.9 build was causing all kinds of weird display problems on my
machine, but I'll go back a few days.

On the other unices, there may be no printcap there by default, but the lpr
system probably is...you may just have to create the printcap yourself....but
I'm just going to digress on this issue because it's not really helping anything.

Comment 5

[Roland Mainz]

ktaylor wrote:
> The printers are working with the the user pref I have, but I'll make that
> change to the line you mentioned.

BTW: This was a recent change to fix a inconsistency... older builds may rely on
the name without "PostScript/" or "printer_PostScript/". I fixed this that
printers always have the "printer_"-prefix (to avoid havoc if a machine has
print quques with the same name as our prefs) and either start with
"PostScript/" (for PostScript module printers) or have a "@² in the printer name
(for Xprint printers) ...

> The latest 0.9.9 build was causing all kinds of weird display problems on my
> machine,

Did you file bugs for these issues ? :)

[snip]
> On the other unices, there may be no printcap there by default, but the lpr
> system probably is...you may just have to create the printcap yourself...

Oh, well... I am getting grey hair about this issue. Sure... I could run
"lpc"/"lpget"/"lpstat" once at installation time and cache the result in the
prefs... but that may result in stale data if the list of printers changes.
Another problem is that a fix for this _must_ not increase startup-time of
mozilla or noone will approve such a patch (therefore I can't run query the list
of printers via "lpc"/"lpget"/"lpstat" at startup).
That's why I recommend the Xprint solution because it has solutions for all
these issues without punishing users nor the admins (admins love it because they
only have to setup the whole thing once on the server side and do not need to
hack the prefs.js for each new Mozilla release) ...

Comment 6

[ktaylor]

>BTW: This was a recent change to fix a inconsistency... older builds may rely >on
>the name without "PostScript/" or "printer_PostScript/". I fixed this that
>printers always have the "printer_"-prefix (to avoid havoc if a machine has
>print quques with the same name as our prefs) and either start with
>"PostScript/" (for PostScript module printers) or have a "@² in the printer >name
>(for Xprint printers) ...



ok. Either way, it is currently working, so I'm happy.

> Did you file bugs for these issues ? :)


Not yet. It's glaring enough of a problem that I'm sure it will be fixed in
tomorrow's build.

>Oh, well... I am getting grey hair about this issue. Sure... I could run
>"lpc"/"lpget"/"lpstat" once at installation time and cache the result in the
>prefs... but that may result in stale data if the list of printers changes.
>Another problem is that a fix for this _must_ not increase startup-time of
>mozilla or noone will approve such a patch (therefore I can't run query the >list
>of printers via "lpc"/"lpget"/"lpstat" at startup).
>That's why I recommend the Xprint solution because it has solutions for all
>these issues without punishing users nor the admins (admins love it because >they
>only have to setup the whole thing once on the server side and do not need to
>hack the prefs.js for each new Mozilla release) ...


You wouldn't necessarily need to run the lpc stuff on startup, just parse the
printcap file (if it exists), then make the printers available with lpr
-Pprinter. I actually meant in my statement that the administrator of the unix
machine would need to create the printcap, not mozilla itself.

I know it's more work, but I'm thinking that maybe a preference dialog box where
you can define separate printers and the commands associated with it would be
helpful...definately wouldn't be a moz1.0 thing.

Comment 7

[Louie Zhao]

I try to get more than the "default" printer in my print dialog using [2] [3] way.
Although I can see the printer-list in print dialog, whatever I select, only the
"default" printer was used. All the printers is printer-list are available(I
test them using lpr -P *). 
Is this a bug of mozilla or my wrong environment setting? 

Comment 8

[Roland Mainz]

Louie Zhao wrote:
> Is this a bug of mozilla or my wrong environment setting? 

I heared this multiple times but was never able to reproduce the problems.
But thanks to "valgrind" (Rational Purify clone for Linux x86) we may found the
reason for these random problems - see bug 161634 ("envvar should not be freed
after PR_SetEnv") ...

Comment 9

[Roland Mainz]

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

Comment 10

[Roland Mainz]

Reopen bug, this is a DUPlicate of bug 161634, not bug 61634 (the '1' is
missing) ...

Comment 11

[Roland Mainz]

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

Comment 12

[sujay]

verified.