Closed Bug 135695 Opened 22 years ago Closed 16 years ago

[ps] Use /etc/printcap to set default printer names and commands

Categories

(Core :: Printing: Output, enhancement, P3)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
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).
Blocks: 110527, 125824
> 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
Does CUPS haqve any API (library) which may be used too query the available
printers and their properties ?
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");
Summary: Use /etc/printcap to set default printer names and commands → [ps] Use /etc/printcap to set default printer names and commands
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/))
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 163751 has been marked as a duplicate of this bug. ***
*** Bug 176128 has been marked as a duplicate of this bug. ***
*** Bug 90947 has been marked as a duplicate of this bug. ***
Blocks: 157675
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:

--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.
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.
*** Bug 172704 has been marked as a duplicate of this bug. ***
*** Bug 214643 has been marked as a duplicate of this bug. ***
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.

> 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
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.

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.
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.
*** Bug 240379 has been marked as a duplicate of this bug. ***
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.
Attached patch LPR printer support (obsolete) — — Splinter Review 
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: rods → kherron+mozilla
Attachment #199880 - Flags: review?(cbiesinger)
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-
Attached patch LPR support v2 (obsolete) — — Splinter Review 
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)
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)
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: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: