Closed Bug 136146 Opened 23 years ago Closed 22 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 161634
mozilla1.2beta

People

(Reporter: ktaylor, Assigned: rods)

Details

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.
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 :) ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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) ...
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.
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) ...
>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.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta
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?
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") ...
*** This bug has been marked as a duplicate of 61634 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reopen bug, this is a DUPlicate of bug 161634, not bug 61634 (the '1' is missing) ...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 161634 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
Summary: Cannot set multiple printers in dropdown printer dialog box → [ps] Cannot set multiple printers in dropdown printer dialog box
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.