Closed
Bug 135695
Opened 23 years ago
Closed 17 years ago
[ps] Use /etc/printcap to set default printer names and commands
Categories
(Core :: Printing: Output, enhancement, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: ewv, Assigned: kherron+mozilla)
References
Details
Attachments
(2 obsolete files)
I know the first response is going to be "Use X-print." I'm sure Xprint is nice, but we use cups here which can be set to automatically generate an /etc/printcap file. My problem is this: I install mozilla for a group of about 20-30 people with about a dozen print queue. Under the current system (as I understand it) I have to change the global prefs.js adding in a line for the list of printers and then add a line that tells mozilla "to print on printer foo, use the command lpr -P foo." I have to remember to do this for every upgrade of mozilla (since they live in their own directories on the cluster) and if I add a printer to the system, I have to remember to add it to mozilla too. Please make mozilla generate these "lpr -P foo" and "lpr -P bar" commands automatically. Then the user could modify them, but at least give them a starting point. I would imagine that this is an even bigger issue for people with bigger installations than us (who don't use Xprint, obviously).
Reporter | ||
Updated•23 years ago
|
Comment 1•23 years ago
|
||
> and then add a line that tells mozilla "to print on printer foo, use the > command lpr -P foo." This part is not neccesary, the default "weired" env var hack does that for you... ---- The problem is that there is no standard way to figure out which print commands should be used or which printers are available. For example: Solaris uses another way than CUPS (and Solaris has changed it's print system between the OS releases, too; 2.5.1!=2.6!=2.7), AIX has it's own solution... HP-UX uses another way and even the syntax of /etc/printcap is not always the same on those platforms which ship with it. Sure... one way would be to ask "lpc"/"lpstat" for the list of all printers - but that solution can be _very_ slow (can take a few mins if there are network printers which are not available) ... The only solution which works across all X11/Unix platforms is Xprint - which is not hard to setup - and you only have to set up one server (Xprt [1]) for all clients and set _one_ env var on the client side (XPSERVERLIST) to teach the client where it can find the Xprt servers (this is the only thing you have to do on the client side, no prefs, no /etc/printcap hacking on the client side). The configuration is done on the server side (which means you do not need to whack the mozilla config each time you update the Zilla) ... [1]=(working) Xprt Linux x86 binary and config files are available from http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_005.tar.gz
Comment 2•23 years ago
|
||
Does CUPS haqve any API (library) which may be used too query the available printers and their properties ?
Reporter | ||
Comment 3•23 years ago
|
||
Yes, http://www.cups.org/spm.html seems to detail the cups printing API as well as an API for discovering printers. So, what you are saying is that for my problem, simply building and environmental variable "MOZILLA_POSTSCRIPT_PRINTER_LIST" (as I recall) with my printer names and forgetting about setting anything in prefs.js is the correct approach? I think cups also works across all Unix platforms too. I'll have to look into xprint as well to see what the differences are.
Well, we use LPRng, which many redhat-installed systems do. I would not mind either having mozilla parse /etc/printcap to add names to the printer-select dialog. Many legacy apps look at /etc/printcap, and generate a list of printers. Anyway, for the record, I have tried fiddling with environment vars like MOZILLA_PRINTER_LIST and MOZILLA_POSTSCRIPT_PRINTER_LIST to get printing working for a list of printers (and of course other things for A4 printing, but that problem is mentioned by others in other bug reports), and have had NO luck. I am now using 1.0 rel candidate 2, where A4 printing now seems to work better. The best solution I have found so far is to edit defaults/prefs/unix.js and just add the the list of printers. For the record it works for me, and I am happy enough that I have upgraded all my stations that were previously 'stalled' at <= 0.96 because of printing problems: pref("print.printer_list", "default recycled lexwhite hp hpcolor office labels"); pref("print.print_paper_size", 1); pref("print.printer_PostScript/default.print_command", "lpr "); pref("print.printer_PostScript/default.print_paper_name", "A4"); pref("print.printer_PostScript/recycled.print_command", "lpr -Precycled"); pref("print.printer_PostScript/recycled.print_paper_name", "A4"); pref("print.printer_PostScript/lexwhite.print_command", "lpr -Plexwhite"); pref("print.printer_PostScript/lexwhite.print_paper_name", "A4"); pref("print.printer_PostScript/hp.print_command", "lpr -Php"); pref("print.printer_PostScript/hp.print_paper_name", "A4"); pref("print.printer_PostScript/hpcolor.print_command", "lpr -Phpcolor"); pref("print.printer_PostScript/hpcolor.print_paper_name", "A4"); pref("print.printer_PostScript/office.print_command", "lpr -Poffice"); pref("print.printer_PostScript/office.print_paper_name", "A4"); pref("print.printer_PostScript/labels.print_command", "lpr -Plabels"); pref("print.printer_PostScript/labels.print_paper_name", "A4");
Updated•23 years ago
|
Summary: Use /etc/printcap to set default printer names and commands → [ps] Use /etc/printcap to set default printer names and commands
Comment 5•23 years ago
|
||
What about writing a script which populates the prefs.js with a list of printers (for those people/platforms who can't use Xprint) ... ---- BTW: I've updated the Xprint server (Xprt) to be compatible to LPng, too (get it from http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_006.tar.gz (or look at http://xprint.mozdev.org/))
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
Comment 9•22 years ago
|
||
IMHO this is an important feature for mozilla to have. I know I have some very confused users here - "why don't I get to pick my printer in Mozilla, it works in everything else!". Now, if I understand things correctly it doesn't matter too much what the format of /etc/printcap is, since at the basic level the only information we /must/ extract from it is the printer names, which are generally pretty consistent. Enhancements to that (ie paper size options, figuring out if a PPD has been speficied, etc) could come later, but the most important thing is to get the print dialog to offer the user a list of printers to use. As for CUPS - it offers its own API for printer discovery etc, and (at least on all the systems I've used) creates a "dummy" printcap /etc/printcap.cups that could be used to detect cups. Of course, implementing any CUPS-specific enhancements would be a separate bug. This bug is only about getting the very basic info about the printer. If you can't "lp printername" then something is broken on the printer config, so we can probably get away with using an otherwise default print command at first. The on two UNIX variants I have on hand, a bunch of Debian machines and a SCO OpenServer 5.0.5 box, the printer names are fairly easy to get out of the printcap. Here's the SCO printcap, as an example of a "weird" UNIX. P1 and P2 are remote printers on another host, and the HP is a network PostScript printer handled locally. # Remote Line Printer (BSD format) P1|P1:\ :lp=:\ :rm=PS530370:\ :rp=L1:\ :sd=/var/spool/lp/admins/lp/prin ters/P1:\ :mx#0 P2|P2:\ :lp=:\ :rm=PS530370:\ :rp=L2:\ :sd=/var/spool/lp/admins/lp/prin ters/P2:\ :mx#0 hp:\ :lp=/dev/null:ex:sd=/usr/spool/lpd/hp:
Comment 10•22 years ago
|
||
--WORKAROUND FOR CUPS USERS-- (ugly hack) As a workaround in the mean time, I've just confirmed that setting MOZILLA_POSTSCRIPT_PRINTER_LIST="printer1 printer2 ... printern" works fine with CUPS. You could (ugly hack warning) pop something in your /etc/profile or ~/.profile or ~/.bash_profile (whatever) like: MOZILLA_POSTSCRIPT_PRINTER_LIST=`cat /etc/printcap.cups | sed 's/:$//'` but be warned, I suck with sed and didn't manage in the 5 minutes I spent trying (sorry, kinda busy) to write a regexp that'd handle anything but a basic CUPS printcap. Expect nasty smoke if you use this with lpd, lprng, etc. Still, it works. I'm using Debian 3.0 with the mozilla built for that, but I'll test it with 1.2 soon.
Comment 11•22 years ago
|
||
I would just be happy with some UI in the printer dialog that lets me add new printers and their corresponding commands (instead of manually editing prefs.js). Why not simply allow to add printers by defining arbitrary commands to pipe the output to? Added benefit would be that I can something like "ghostview -" for a quick preview of how the postscript gets rendered.
Comment 14•21 years ago
|
||
Something that I haven't seen raised about CUPS anywhere in Bugzilla is that more than just another *NIX print system, it is an IPP (Internet Printing Protocol) system, with a reasonably well documented API. If deployed correctly, it allows printing to any IPP printer on the Internet (well, Intranet, I would hope), including Microsoft (since W2K) and Novell servers(Since NetWare6). Why I'd like to see it: For a special-purpose system I've been working on, I need a browser to print to a weird printer with some weird paper sizes (specifically, a receipt printer with a thermal transfer paper roll) on a Linux- from-scratch system; this has had me spending days trying to figure out how to patch Mozilla to do it. I had to choose between PostScript and Xprint, and couldn't see the benefit of Xprint, since it could also only handle a pre- defined set of paper sizes. So I've been hacking the PostScript module. However, if CUPS was an option, I would have been finished already - I had to write the CUPS driver for the printer, which included specifying paper sizes (CUPS can also support custom paper sizes - you define maximum papers sizes and the application tells CUPS how big the page is for a particular print job). If Mozilla supported IPP, it would have understood my printer without me needing to hack it. Konqueror does it perfectly, but was not appropriate for my project.
Comment 15•21 years ago
|
||
> couldn't see the benefit of Xprint, since it could also only handle a pre-
> defined set of paper sizes. So I've been hacking the PostScript module.
You can't seem to specify the custom sizes from Mozilla itself, but you can
certainly add the paper sizes to the Xprt config files:
/usr/X11R6/lib/X11/xserver/C/print/models/YourModel/model-config
Comment 16•21 years ago
|
||
This has got to be one of the stranger shortcomings of Mozilla. Actually, I'm using Firebird now but the same thing applies. I don't know anything about xprint, or prefs.js, or APIs or other techno terms. All I know is that on my new Red Hat 9 install, the Print Manager saw all of my network printers right out of the box using cups. All of my apps - OpenOffice, gimp, evolution, etc - have a printer selection menu that includes all of the printers that the Print Manager saw. All except Mozilla and Firebird, that is. It's not clear to me why the same methods that these other apps use to see printers can't also be used in Mozilla. But regardless of the technical reasons, this is a real shortcoming IMHO and one that I'm anxious to see quickly resolved.
Comment 17•21 years ago
|
||
Here's something I raised in bug 218096, but is probably more applicable here. There seems to be a fair number of bugs/RFEs on improving the Mozilla Print Manager in various ways. But to me, that's like reinventing the wheel. Good Print Managers already exist - QTCups, kprinter, XPP, Red Hat's Print Manager, etc. We ought to allow the user to configure Mozilla to use an external print manager instead of its own. It cannot be too difficult to pipe output to the print manager of choice since every other app (at least in the KDE world) does. This solves a number of problems: 1. Chances are the user has already sorted out printing on their own machine, including configuration, so we can avoid forcing the user to configure printing yet again. 2. Mozilla can get away with a basic Print Manager, since it won't need one with all the bells and whistles. 3. Avoids the apparent problem of having to support CUPS directly (I really don't understand the problem with CUPS - and if there are problems, we'd probably be better off working with the people behind CUPS than to create a 'rival' system, but that's an aside). 4. Avoids having two print managers to go through to print something. Right now I get Mozilla's lacklustre print manager, select PostScript/default, configure it (once luckily) to use kprinter, press "Print". Then I get the kprinter print manager, where I can actually select the printer I want, number of copies, collated, reverse order, print quality, etc. Even when I print to file I go through kprinter since Mozilla's filepicker is such a pain to use, especially compared to KDE's which of course is invoked by kprinter when printing to file (why Mozilla can't make provision to use KDE's file picker I do not know, but if I can avoid Mozilla's awful file picker I will - sorry for another aside). At any rate, I think we'd do ourselves a favour by making a provision to use an external print manager. Fortunately I don't print much, but if I did Mozilla would soon become a drag compared to Konqueror.
Comment 18•21 years ago
|
||
This has obviously needed fixed for some time; it needs to be done. A friend is using a new install of Mandrake 9.2 for his home system. Everything works fine with his printer except Mozilla and Firebird. He has only a single home computer. No server, no Unix administrator. Just a single home user who is not a Unix techie. It is obvious to him, and to me, that Mozilla and Firebird are broken. All the technical explanations about how to make it work seem like just excuses. It should "just work", like everything else.
Assignee | ||
Comment 20•20 years ago
|
||
What I'd like to do is add enhanced lpr support similar to the CUPS support that was added in 1.7/1.8. To discover lpr printers, mozilla would check for /etc/printcap (configurable via a pref). To print to them, mozilla would construct an lpr command line and run that, rather than the current scheme of running an opaque command that's probably lpr. In principle we could support lp the same way, though printer discovery is more difficult; see bug 240379.
Assignee | ||
Comment 21•19 years ago
|
||
This adds direct support for printing through lpr. It reads a printcap file (/etc/printcap by default) to get the list of printers, and then prints by constructing an lpr command line. I've tested this using the CUPS lpr emulation on my system, but I've reviewed the LPRng documentation and it should work with that too.
Assignee | ||
Updated•19 years ago
|
Assignee: rods → kherron+mozilla
Attachment #199880 -
Flags: review?(cbiesinger)
Comment 22•19 years ago
|
||
Comment on attachment 199880 [details] [diff] [review] LPR printer support (can you add -p to your diff options in the future?) gfx/src/psshared/nsPSPrinters.cpp + nsCOMPtr<nsIPrefService> prefSvc; + prefSvc = do_GetService(NS_PREFSERVICE_CONTRACTID, &rv); can you merge these two lines? + ch = getc(aHandle); is there a particular reason not to use fgets? + ch = getc(aHandle); + if ('\n' == ch) { + ch = ' '; + } + else { + ungetc(ch, aHandle); I don't think that this code handles EOF from getc correctly... + if (isascii(aName[i]) && !isalnum(aName[i]) && + !strchr("-_@.", aName[i])) + // Skip this printer + return PR_TRUE; I think this might be easier to read with a {} around the body of the if +static PRBool +AppendLprPrinter(nsCString& aName, void *aData) why PRBool? You always seem to return true... gfx/src/ps/nsPrintJobPS.cpp +static const char gFallbackJobTitle[] = { "Untitled Document" }; no need for the {} here... + * or "Postscript/default". The "<printer>" portion of this string is stored uppercase S in PostScript :-) + nsCOMPtr<nsIPrefService> prefSvc; this is C++, you can declare variables where you use them :-) (I don't like having unitialized variables around) + nsCAutoString command(nsPrintfCString("%s -P '%s' -J '%s'", I think you need to set a larger string length here... (http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsPrintfCString.h# 74) gfx/src/ps/nsPrintJobPS.h + * Launch() should be called first. do you mean Open()? various times in this file, in fact... +class nsPrintJobLPR : public nsIPrintJobPS { hm... can you use "virtual" for those functions which are virtual? makes it easier to see which are actually overridden from the base class hm... none of this file does that... better to be consistent then, I suppose
Attachment #199880 -
Flags: review?(cbiesinger) → review-
Assignee | ||
Comment 23•19 years ago
|
||
This should address the review comments. In the printcap-reading code, I had used getc() to optimize code size and complexity. Here I've rewritten it to use fgets(). The code is a little larger and more complex, but it's about 2-3 times as fast. Regarding AppendLprPrinter() returning PRBool, it's a callback function so its signature is predefined.
Attachment #199880 -
Attachment is obsolete: true
Attachment #201944 -
Flags: review?(cbiesinger)
Assignee | ||
Comment 24•19 years ago
|
||
Comment on attachment 201944 [details] [diff] [review] LPR support v2 I'm putting this on hold. I'll revisit it after bug 317450 has landed.
Attachment #201944 -
Attachment is obsolete: true
Attachment #201944 -
Flags: review?(cbiesinger)
Assignee | ||
Comment 25•17 years ago
|
||
This was fixed by the patch for bug 193001. Gecko now prints through the GTK printing API, which includes LPR printer detection.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•