UWVFP( FP0 ‹؋F&O F&G&G<ʋЋ™Ƌ$6&~&6&F&9EtL2pP3P F&EĞ&(6&>pt*6&>vt TF&EF,6&>~FvFĞ&^&9~Ì~ڹ-F*Ftz8ft F^&8Gui~t F^&8GuWF+F;F| F9Fu~tF@t8F^&8Gt,F+F;F~<.6&>t0^&GĞ&v&@F[FF,6&9~2F^&8Gu FuӋvzvĞ&7X06&?&&DPĞ&&& 26&>|u 46&z66&^&Gȋƻ[؎86&>&I86&&a~t;F*PĞ&&& 46&zF*Pv:6&& ud26&>|u 46&zĞ&&& <6&6&6` P, >6&F&H t8PP  |FPPh P:6&6&6P  |FPPh P*6&>vt BlPP] @6&6&6`Ğ&&& pP B6&R&TĞ&7FD6&FF6& fĞ&7FtH6&&J6&H6&J6&f%=؎L6&FD6&FF6& ^_]ːUVN6&6 &6rP N6&6 &6"P vPrPh P"Ph FPrPXX @uNFP"PXX @uQN6&6 &6"P P6&6(&6&"Ph FP"PXX @uFV9Vvr9Fv~} ~[sPrPC uƆrPrPVj3 6d6brP  udpP~QPVj3 FPF-P86&6&6VP R6&[RPFV-RP ,6&V2 ^]UWV+PP( FVN6&6 &6FP N6&6 &64P PFPh P4Ph FP4PXX @uQN6&6 &64P P6&6(&6&4Ph FP4PXX @u3FV9Vw1r9Fs*FVFV06&X&& FVFVFVPPFPC uP6d6bVh4 pP~QPVh4 3,602&9?~Dv3ɉNރ,.&Gt &u&g[GĞ0&9?ЋvFP[Ğ0&/P86&6&6VW V2 FPFPR ^_]ːUTWVN6&6 &6FP PFPh PFP V t)FPVQpQ~RQx WV ^_]ːU"WVFP( FP0 V<&m&EFT6&F&M FF &EF~,6&F 86&&؉V$6&FN9Nu~t F&u|v&DF&8G tl&G *Fta&G:F t F&D8FuJF&G9F t F&D8Fu0Fw&F;FF&@t+~9~~~[A9N~a~}+FFf~@~F39N86&&>؉V~؃~t Fw&uZFw&*FtJF&F t F&8Eu4Fw&F t F&8EuFw&FF;F}F[A9N~V~t}^_]ːear all searchUWVP V t5P6  u$FPVVP VPƆVPVPh FPVPXX  t$VPP(P P ~WP V u P(P P P-PVP26 FV u$VP0P(P P vvWPvV ;t2VPLP(P vv P vv  t$VPwP(P P F  3RT&7&GLX"3NP&&G&MVv~~؎ZX&&+NjV&&PIuvĞN&F&7&GĞR&&&GÌV&$3& &> & & ߎ&&3&OF&&&ʋH(3JL&&G*3&&F&ʋFPQ" @FĞJ&&?~G~VvN~&&+NjV&&PAĞJ&&9ڋ~v*3&F&7&GĞJ&&@&GF,3&> & M.3& & ^_]ː&u0 U.WV4Z9&3\9&6^9&"`9& b9&r d9&bf9&dh9&fj9&h+ɉNNvvZ RP"Pr QP V^V۹^VNVl9&>nu-n9&X&B&@ "P| 3br QP t~ PvvP t!2PP] p9&tN릐2PP] p9&u, QP2PP] p9&u0 ~+PP( FVP+PP( ȋ+FV~9&&SQvvvVr FV~9&&d3SQRP FVdRPvv FVvvRP<RPSQRPvv⚺ RPFމVT SQvvމFډVܚT <3SQvvF։Vؚ FV؋Nڋ^+SQF҉VԚT +FVRPvvvvvvZ RPn9&X&r&p N~9&pr9^F&?tt9&>vt^&?t;^9&>"u\9&>6u `9&> tPvv^&?tMt9&>vtAPPv9&68&66`Px9&GPv9&68&66 tظ[.ظ&&،F&Gt1&9}&Gع&;z ~36&z F&9G|&F u &>tF&Gu & t~u &>tF&Gt & uPvvP t}pr9^F&?tMt9&>vtAPPv9&68&66`Px9&JPv9&68&66+PP( FVz9&>|u |9&z, QP |%^&?tMt9&>vtAPPv9&68&66`Px9&GPv9&68&66PvvPn9&X&F&D PvvPr9&>ptMt9&>vtAPPv9&68&66`Px9&GPv9&68&66^_]UWV P3Z9&P QP 9+&& ~ u19&9>"t2PP] p9&u |] u9&9&F |#[n9&&@t 9&2P P] =tz9&>|u |9&zr9&>ptt9&>vtT9&>"t2PP] p9&t t3Pt9&N& LtsdP FV|] t6~vv`  u!dP FV] |] u͚] 3P9&6N&6LtmpP FVRP`  tP~|] t@2P P] =t* vv`  t 3b2PP] p9&t;3PN^9&>"u\9&>6u `9&> t N(^_]ːUWV9 &?|%[&/9&&~ڹ-Ğ &?}^9&>"t5~t/F*Pn9&X&N&L F*P3~9&& t1B*PWn9&X&R&P B*PFF;r `9&?u \9&>6t?Ğ &?|5~t/F*Pn9&X&V&T F*PO9&& uĞ&?u\9&>6u^9&>"un9&X&Z&X 9&6&6` P, 9&6&6P Ğ &?|FPPh PPP] n9&X&^&\ 9&6&6`pP 9&R&T3^9&"\9&6Ğ&^_]ːU욀"P9&6&6n9&X&& 9&6&6`嚖t9&>vt9&63P] 9&>Ltr 9&>du.] v ]UVv u3, ȋƙ+T؋ʙùdP ^]ːUWV~9&B&DF&9Eu &9U u&E & Eu 9&&9&6&6KP KP" KF^F9&& u~N؋W&9Du&9T tGG u9&&V uVV‹&?u$~9&>t3"PvW ~^FFG&<u^&7"PvW_9&6&6KP KP" K^9&F&9t&9&>uF&5"PDvP K^_]ːUt9&>vur9&>pu3P, 9&@P"Pr QP PQ9&6&6`r QP9&6&6mcha^n Trung co^.ng. Ve^` bo^. chie^'n, dde^? cho^'ng la.i cuo^.c chie^'n tranh qui u+o+'cco^? ddie^?n, ddo^'i phobF t'P9&6&6"Pr QP $9&6&6 #Pr QP PQ9&6&6`#P9&6&6ZPP9&6&6`r QP9&6&6Z3P9&6^ ]ːt9&>vt&r9&>pt P9&6&6ːU.WV~FL^ }dǹ[FԻ9^֌F&&GtFLBƌ@V~t ‹F& ^&^&GtFF&C~t FF& ^&^&GtFF&D~t FF& ~t$^&^&G@tFF&FFF& ^&^&GtFF&H~t FF& ^&^&GtFF&K~t FF& ^&^&GtyFF&L~ti^&^&GF |@P+# +FP0#PFP FڌҋȎڋ6?t!vNG^F&=uv~~t$^&^&GtFF&MFF& ^&^&GtFF&N~t FF& ^&^&GtFF&S~t FF& ^&^&G tFF&R~t FF& ~t^~&=&At FF&XF&FL^_]ÐUt9&>vur9&>pu9&>u3P9&6+RP9&@P5#Pr QP PQ9&6&6`r QP9&6&6Z PP9&6&6`vv9&6&6ZT]UWV3Pz9`b&?}Tt9&>vuEWĞ`&@PXn9\^&&f&ddP PP9XZ&w&7`dPĞX&w&7ZPĞ`&7‹؋F&?tTPVĞ\&&j&hdP PPĞX&w&7`dPĞX&w&7Z9TV&G& u9&w&7dP A#PdPh PJ#PdP26 V uFPVQQNQ FWV ~uvrĞT&w&7dP M#PdPh 3PdQNQ*6 uqvFP ;PdPFP*6 t@2PPĞX&w&7`Ğ\&&n&lĞX&w&7ZT^_]R$bCLSU.WV4 ع4& &QP( 4+&,&*&(&0&.p4^F&9t&4&9vtotice and authorship remains intact. &?u-~ٹ~t%FFF4&F ~FFFP RP4&6&6 Pr QP r QPB FP RP Pr QP r QPB F ~js)+FFFFFF4^ތF&4&>v% 4^ڌF&4&>x ^&4& 4&9s 4&> t^&3PN։VRQQD~u QPP  tuHtpHtHHtMc uW^&^&ub4&h4&d4&X&& 뤚 u ^&^&u2봎4&h3P4&T4&ht F҉NԐ3^&9?~14&t&4 QPF  uG^&9?ҚHuHuGHtvHu}W4&t ;E2PP] 4&u)FPP 3PvvָP4& u^&^&t4&d4&h4&X&&  u^&^&t밐62PP] 4&u_4&>tPFPP 3PvvָP"2PP] 4&uFFPQ F4&^&?tp4&>vtd4&6&6 Pr QP PP4&6&6`r QP4&6&6ZT4&h3PO QPP 4&^&?tp4&>vtd4&6&6 Pr QP PP4&6&6`r QP4&6&6ZT4&T4&h QPP 4&^&?tp4&>vtd4&6&6 Pr QP PP4&6&6`r QP4&6&6ZT3P5& 5&b4&d5&f4&hPvvָPf3PvvָPQ^_]WV+ &&r & &6&"&& & ع^_ːUVXP FVRP`  uuv2PP] 4&tY uP2PP]  tFF& t*<t&P]  vv`  t'2PP] :] P ] 3^]ːU(WVb5&?u]v vFVF tHt#HuHuHu)F396F~(D Pv vWd u F;6F|ۋ~F &}t=&u&uvv PbP F &u/ PFP 2vvbP F &u&u8 PFP FLJFĞ&7bPE PP T PP V us5&& tZFLJFbP Ğ&7bPW PP f PP VF u-~ uyP4&X&>&< UFPV FPbPh bPP<  uX9F t!bP4&X&B&@ FDF^FFV ~~ t+v vZ RP4&X&F&D PB >Fuy396F~%D Pv vWd t F;6F|96F/~ u=v vZ RP4&X&J&H~F &}t=&u&uvvi PbP F &uy PFP 2vvbP F &u&u PFP F?t5&6&6bP FPbPh F;6F}rFFFFDFDFF+ƉF~vF^^F^FF F NuFbPB  u$9F ubP4&X&N&L?~ ubP4&X&R&P 5&& uĞ&7P PbP  PbP RP D5&& t-Ğ&7P PbP bPB 3^_]U($ 5^ތF&?u5^ڌF&G& u  t6 6 `  udP   5&bF tP^&w&7 PNFP ^&w&7 PNFP FPNFPXX  uDNFPB ^&74&X&&  5&z^&7]39&RzLxL9&9ptI9&9vt>PP9&6&6`#P9&6&6ZT#P| ] 9&$PP] P u 9&X&N&L 3n9&>ptJ9&>vt>PP9&6&6`#P9&6&6ZT$P| PV39&RzLxL9&9ptH9&9vt=PP9&6&6`&$P9&6&6ZT H$P| :] 9&$PP] 3PN tz9&>ptK9&>vt?PP9&6&6`S$P9&6&6ZTu$P| 3P u4^ːUWV9& & VȋڀFV$PSQ $PvW QPr9&QPZ RP$P 9&QPZ RPvW'3FF9&9~Q~9&9>t,$PvvPVZ RPvv G9&9>~$PvW89^F+&G&9Ft QP: '~uZzL0QP: ~9^&G& t-P&w&7vv< ^&GSvW%$PvW~t)9&>^u9&>`t$6$1$+9&t$PvW9&u$PvW$PvW9&> بt+& ~u:& #Ft&ِFtvt &6 بt$`~t6t$PvWt$PvWƨt3$"t$t$ ƨt$PvW9&t~t9&>zu$PvW$PvW$PvWw$PvWh9&>ju9&X&&$ډFVRP9&69&6$PP%Pvv vvvW%PvW9&6&69&6&6:&6&6#%Pvv vvvWB:&6&6:&6&6:&6&60%Pvv vvvW=%PvWD:&&&(0T|RPE%Pvv vvvW vW" 9&$PP] FpP FVv~vvO%PvV vV" PvVj! FPQ\%QJ] PvV" PvVJ] PvvvJ] F~~;~v^^؋NJ*3QNJ*&3ZF;v|։~v] v_%PvV PvV" PvVJ] FF=vP FVvv`  t 2PP]  :&uvv`  t|] u t 3P( -*ui%PvV vV2 ui6`#6^#vVF  uN6p#6n#vvF  t~9&X&&e%PFPW ƋFv2PP] 9&X&&V\2PP]  :&u9&X&&ˎ9&X&&k%PFPV NjFvW 3^_]U WVFdžPƆ{dž8o%:dždž@~%BdžD%FdžH%J+NL9& & vx~prt89 +&G&n9&9ptH9&9vt=PP9&6&6`%P9&6&6ZT %P| T :&P FVpP FV+FF{{<vv~uZ6`#6^#%P~V P~V" P~VJ] 2.8 PostScript utilities 2.9 TeX/dvi 2.9.1 `dvips' 2.9.2 `eps' 2.9.3 `dvilj' 2.10 texinfo 2.11 Printing though a terminal 2.12 hardware and drivers 2.13 Printer device names 3 LPR 3.1 Setting up print services 3.1.1 Remote Printing Vs. Local Printing 3.1.2 What You Need 3.1.3 How Printing Works Under Linux 3.1.4 The important programs 3.1.5 The `lpr' Command 3.1.6 The `lpq' Command 3.1.7 The `lprm' Command 3.1.8 The `lpc' Command 3.1.9 The Important Directories 3.1.10 The Important Filercial platforms can use the display PostScript renderer to render the fax image; this is not yet an option under Linux. The GNU program netfax supports Class 2 fax modems only. It builds nearly out of the box under linux. I have patches for version 3.2.1; you can get them from the printing mail server as `netfaxpatch'. It runs a server and accepts jobs into a queue from the local machine and the net. Netfax is in use at MIT. It accepts PostScript, dvi, and ascii, and can be configured to work as an email gate. Documentation in the package is limited to compile notes and man pages for the individual programs; actual installation tips are few and far between. `prep.ai.mit.edu:/pub/gnu/fax-3.2.1.tar.gz' FlexFax is available from: `sgi.com(192.48.153.1):/sgi/fax/?????.src.tar.Z' It is written in C++, and thus requires g++ to build. FlexFax supports class 1 and 2 modems, uses ghostview (or a display PostScript server) for rendering, and generally is more complete, or at least general than the somewhat MIT-specific netfax. It also can run in place of getty and either receive a fax or spawn a login as appropriate for the type of call. It includes precise instructions on configuring smail3, sendmail, and other mail agents to send mail for so-and-so@12345678.fax to the fax at 12345678. This is the package I recommend if you have real faxing needs, as it is properly documented and full-featured. Version 2.x of FlexFax is in real release now and fully supports Linux - just type `./configure' and `make'. mgetty+sendfax is a Linux and SCO-specific getty for faxmodems and a simple sendfax program. This package is available as `sunsite.unc.edu:/pub/Linux/system/Serial/mgetty+sendfax-0.16.tar.gz'. This is a good package for those who need to send a fax every now and then. Finally, `efax' deserves mention. Class 2 only. no net, no mail, just send a tiff. Efax is available as: `sunsite.unc.edu:/pub/Linux/apps/comm/efax05.tar.gz' 2.6 *roff, man pages ==================== Man pages can sometimes be printed straight from the cat pages (in lieu of the normal nroff source pages) as though they were a normal text file (which they mostly are). However, many printers do not like the control characters for highlighting and what not that is imbedded in these. A filter for this purpose comes with the net-2 lpd package. If you have the nroff source to the page (the finding of which I highly recommend) you can say `man -t foobar | lpr' and your man program will (hopefully) format the man page using groff into PostScript, which will then be sent to your lpd and on to the printer. This form of man page output looks MUCH better than the plain ASCII version. Unfortunately, this depends very much on which man program and what supporting software you have installed. If your man doesn't do this, you might try the perl version of man, available near: `sunsite.unc.edu:/pub/Linux/system/Manual-pagers/' It is written entirely in perl, and is thus easily customizable (perl being an interpreted language reminiscent of C and sh). You can also find the nroff source file in the man directories (most versions of man have an option to just spit out the filename) and do it yourself, into any format supported by groff. groff -mandoc -TTYPE foobar.1 | lpr Where TYPE is one of `ascii', `dvi', `ps', `X100', `X75', `latin8'. 2.7 Printing text via PostScript ================================ There are a number of utilities to allow text to be printed to a PostScript device. 2.7.1 mpage ----------- The package mpage converts plain text into PostScript and/or prints more than one page onto each peice of paper given PostScript or text. It is available at (or at least near): `wuarchive.wustl.edu:/pub/mirrors/unix-c/PostScript/mpage.tar-z' Note that wuarchive uses the `-z' suffix to mean `.Z', ie, `compress', not `gzip' or `freeze'. `man -t foobar | mpage' will send a 2-up (depending on the environment variable MPAGE) version of the man page to lpr and its PostScript interpreter. This saves paper and speeds up printing. 2.7.2 a2ps ---------- A2ps will take ASCII and turn it into a nice PostScript document with headers and footers and page numbers, printed two pages on one (or otherwise, if you say so). A2ps does a very nice job at this. It is available at the same place mpage is. Not that if you have a deskjet, many n-up programs will run into trouble by trying to print in that last half-inch. 2.7.3 enscript -------------- Enscript is a program which does basically the same thing as a2ps. I do not know where to get it. It comes with most commercial Un*ces. A clone version of enscript is called nenscript, available on `sunsite.unc.edu' as: `/pub/Linux/system/Printing/nenscript-1.13++.bin.tar.z' `/pub/Linux/system/Printing/nenscript-1.13++.tar.z' 2.7.4 gslp ---------- Gslp is one of the uilities which comes with ghostscript 2.6.x and purports to do the same ascii => ps conversion as enscript and a2ps. I have not used it, but the docs say that gs -q -sDEVICE=????? -dNOPAUSE -- gslp.ps TEXT.FILE [OPTIONS] should do the trick. (`gslp.ps' is the actual program, which is written in PostScript. Here it is run with the argument TEXT.FILE. PostScript is in many respects a programming language more than a mere printer command language.) Further documentation is in the file `gslp.ps'. There is a script file which does the above for you. 2.8 PostScript utilities ======================== Those of you who deal with large amounts of PostScript may wish for more utility programs. There are probably millions of little programs which do things to your PostScript. A representative package of them may be found in: `achilles.doc.ic.ac.uk:/tex/inter/psutils/' `ftp.cs.psu.edu:/pub/src/psutil.tar.gz' These handle page selection, double-sided printing, booklet creation, etc. Most large ftp sites (eg, `wuarchive.wustl.edu', `ftp.uu.uunet') will have many such packages to choose from. 2.9 TeX/dvi =========== [La]TeX is the text formatting package used by many in the academic world and elsewhere. TeX works much like any other compiler - source code is run through the program `tex' to become a `.dvi' file (analogous to an .o object file in C) which can be further manipulated to produce printed output (a "binary"). This manipulation of a dvi (DeVice Independant) file usually takes a little bit of doing. It is well worth it; TeX's output is of professional quality. If all you are given is a file with a `.tex' ending, try either `tex file.tex' or `latex file.tex'. One of these is bound to work. Then you have a dvi. (You may have to run it twice for indexing) For those in the real world who cannot afford a dvi understanding printer, it is usually necessary to convert the dvi something the printer understands. These programs may be run manualy but are often built into lpd filters. See Also: Writing lpd filters. 2.9.1 `dvips' ------------- `dvips' converts dvi into PostScript that you can pipe into ghostscript or send to a PostScript printer. Most installations come with functioning installations of both TeX and `dvips'. Typing `dvips -f1 file.dvi | lpr' will do it. `dvips' responds to either command line arguments or a file `/usr/TeX/lib/tex/ps/config.ps' (in the usual TeX layout, at least) in which you can arrange to have dvips automatically send its output to `lpr'. Thus `dvips file.dvi' will do everything that needs to be done. Note that some `.dvi''s may include PostScript graphics in the `dvips' stage rather than the TeX stage of the game; if they are not found, you will get a hole instead of a picture. This follows naturally from the object file analogy above. Usually, pre-made documentation in this form has a makefile or script to do everything for you. The LILO documentation is an example of this. `dvips' has several interesting options; for example, `dvips -r1 file.dvi' will print it out backwards. We deskjet users love this one. 2.9.2 `eps' ----------- Eps is a program which converts dvi files directly into the standard Epson printer language; thus it is a dvi driver for epsons. I beleive it supports MakeTeXPK, the automatic font rendering system used by many dvi drivers, and is available as: `sunsite.unc.edu:/pub/Linux/apps/tex/eps-061.tar.gz' `ftp.ctd.comsat.com:/pub/' Note that it is still coming out with new versions fairly often, so there may be a newer version than 061. 2.9.3 `dvilj' ------------- For LaserJet owners, there is a separate program that will take dvi and convert it directly into your printer's language (PCL). It is called dvilj2p or dvilj, and if not on tsx or sunsite, is certainly available on ftp.uu.net. (Description by Nils Rennebarth) Its a nice driver, but a little out of fashion in the sense that configuration (especially of font-paths) font-paths is not very flexible and that it doesn't support virtual fonts (at least the version 0.51 not). The biggest advantage over the dvips/ghostscript combo is that it uses downloadable fonts which: * reduces data transmission to the printer drastically, which makes the printer usable even on a serial line. * reduces printer-memory-requirements drastically. A standard Laserjet with 512k memory is able to print almost every TeX-document. It has support for double side printing and most options you expect a driver to have. It compiles cleanly and worked flawlessly on our diverse hardware here. 2.10 texinfo ============ This is the native documentation format of the GNU project. Emacs can be coerced into producing an info file from TeXinfo, and TeX can produce nice printed documantation from the same file. It is a bit of a stretch for both systems, but it works. It is really just TeX source which expects the macro file `texinfo.tex' to be installed on your system. Just do `tex FILENAME' twice (for index generation purposes), and you end up with a plain dvi file, to print or preview at your leisure. In Emacs, you can also do `M-x texinfo-format-buffer' to convert the texinfo file into an info file viewable with Emacs `M-x info' or an info viewer of your choice. There are also separate programs which read and format info from a texinfo file. These are available in: `prep.ai.mit.edu:/pub/gnu/' 2.11 Printing though a terminal =============================== Many terminals and terminal emulators support the connection of a printer. The computer the terminal is conected to may then use a standard set of escape sequences to operate this printer. DEC VT's and most other ANSI terminals should offer this capability. A simple shell script will enable you to print a text file using the printer connected to your terminal: #!/bin/csh -f # Transparent printing on a vt100-compatible terminal. echo -n \[5i ; cat $* ; echo -n \[4i If this script is called `vtprint', then `vtprint [FILENAME [FILENAME]]' will print file(s) (or stdin if no file were specified) on your printer. 2.12 hardware and drivers ========================= There are two ways the kernel driver may be used to run the parallel ports. One, the original, is the polling driver. The other is the interrupt driver. In principle, the interrupt driver only deals with the port when it gets an interrupt and should therefore be more efficient. In practice, people have found that it depends on the machine. It probably doesn't make too much difference in most situations. For the polling driver, you may adjust its polling frequency with the program tunelp without kernel twiddling. The actual driver is in the kernel source file `lp.c'. To choose the interrupt driver rather than the polled, use the program tunelp to set it. (tunelp is available on sunsite, or from the printing mail server.) Just put the appropriate line in `/etc/rc.local' Seven is the usual "LPT1:" IRQ, 5 is usual for "LPT2:" for an AT class machine. Note that if your printer is on lp0, the interrupt driver will probably not work. The first parameter should already contain the correct i/o base address. Many bios boot screens have this information if you need it. DOS uses a polling driver so if you find that your printer works in DOS but not in Linux then you should try the polling driver. `tunelp' is available from the printing mail server or: `sunsite.unc.edu:/pub/Linux/system/Printing/tunelp-1.0.tar.z' 2.13 Printer device names ========================= On an XT bus system `LPT1:' becomes `/dev/lp0' (major=6, minor=0), on an AT `LPT1:' becomes `/dev/lp1' (major=6, minor=1). To be more precise: Name Major Minor I/O address lp0 6 0 0x3bc lp1 6 1 0x378 lp2 6 2 0x278 For a serial printer use the `/dev/ttyS?' (or `/devttys?', if you follow that scheme) device, not the `/dev/cua?' device. The `/dev/ttyS?' devices have major 4; the `/dev/cua?' devices have major 5. 3 LPR ***** This chapter used to the the `lpd-FAQ' then it became part of the `Linux-FAQ' and now it is part of the Printing-HOWTO. Who knows where it will go next? 3.1 Setting up print services ============================= This section was originally writen Karl Auer 1/11/93 and has now been included here because it was felt that the Printing-HOWTO, being written in the style of a reference manual, was not doing its job properly, since it did not describe in a straightforward way what you need to do to set up print services on your Linux machine. So far it has been included with little modification and may replicate or even contradict information elsewhere in the HOWTO. The overview it gives should nevertheless be very useful to those new to bsd print spooling. 3.1.1 Remote Printing Vs. Local Printing ---------------------------------------- Remote printing is allowing people to send print jobs to your computer from another computer. This will be needed if, for example, you are running as a server in a network, or if a printer attached to your machine is to be accessible from other Unix hosts. Local printing is allowing users on your machine to send print jobs to a printer attached to your machine. There is a third combination too - your own use of remote printing on other Unix machines. That is, where you wish to print on a printer that is not attached to your own computer. 3.1.2 What You Need ------------------- This document assumes you know how to edit a text file under Linux, and that you have a basic understanding of file ownership and permissions. It also assumes that you have your Linux system set up and running correctly. In particular, if you are going to use remote printing your networking subsystems must be installed and operating correctly. Check out the man pages on the commands `chmod' and `chown' for more information. 3.1.3 How Printing Works Under Linux ------------------------------------ The simplest way to print under Unix (and thus under Linux) is to send the print data directly to the printer device. This command will send a directory listing to the first parallel printer (LPT1: in DOS terms): ls > /dev/lp0 This method does not take advantage of the multitasking capabilities of Linux, because the time taken for this command to finish will be however long it takes the printer to actually physically print the data. On a slow printer, or a printer which is deselected or disconnected, this could be a long time. A better method is to spool the data. That is, to collect the print data into a file, then start up a background process to send the data to the printer. This is essentially how Linux works. For each printer, a spool area is defined. Data for the printer is collected in the spool area, one file per print job. A background process (called the printer daemon) constantly scans the spool areas for new files to print. When one appears, the data is sent to the appropriate printer or *despooled*. When more than one file is waiting to be printed, they will be printed in the order they were completed - first in, first out. Thus the spool area is effectively a queue, and the waiting jobs are often referred to as being "in the print queue", or "queued". In the case of remote printing, the data is first spooled locally as for any other print job, but the background process is told to send the data to a particular printer on a particular remote machine. The necessary information that the printer daemon needs to do its job - the physical device to use, the spool area to look in, the remote machine and printer for remote printing and so on - is all stored in a file called `/etc/printcap'. The details of this file are discussed below. In the discussions that follow, the term "printer" will be used to mean a printer as specified in `/etc/printcap'. The term "physical printer" will be used to mean the thing that actually puts characters on paper. It is possible to have multiple entries in `/etc/printcap' which all describe one physical printer, but do so in different ways. If this is not clear to you, read the section on `/etc/printcap'. 3.1.4 The important programs ---------------------------- There are five programs which comprise the Unix print system. They should be in the locations shown, should all be owned by root and belong to the group daemon and have the permissions shown here: -rwsr-sr-x /usr/bin/lpr -rwsr-sr-x /usr/bin/lpq -rwsr-sr-x /usr/bin/lpc -rwsr-sr-x /usr/bin/lprm -rwxr-s--- /etc/lpd The first four are used to submit, cancel and inspect print jobs. `/etc/lpd' is the printer daemon. (The locations, ownerships and permissions given here are a simplification and may be wrong for your system *note lpd files and permissions.) There are man pages for all these commands, which you should consult for more information. The important points are that by default `lpr', `lprm', `lpc' and `lpq' will operate on a printer called `lp'. If you define an environment variable called `PRINTER', the name thus defined will be used instead. Both these may be overridden by specifying the printer name to use on the command line thus: lpc -PMYPRINTER 3.1.5 The `lpr' Command ----------------------- The `lpr' command submits a job to the printer, or "queues a print job". What actually happens is that the file you specify is copied to the spool directory (see above), where it will be found by `lpd', which then takes care of moving the data to the physical printer. If you don't specify a file, `lpr' uses standard input. 3.1.6 The `lpq' Command ----------------------- The `lpq' command shows you the contents of the spool directory for a given printer. One important piece of information displayed by `lpq' is the job id, which identifies a particular job. This number must be specified if you wish to cancel a pending job. `lpq' also shows a rank for each job in the queue - "active" means the file is actually printing (or at least that `lpd' is trying to print it). Otherwise a number shows you where in the queue the job is. 3.1.7 The `lprm' Command ------------------------ The `lprm' command removes a job from the queue - that is, it removes unprinted files from the spool directory. You can either specify a job id (obtained by using the `lpq' command) or specify `-' as the job id, in which case all jobs belonging to you will be cancelled. If you do this as root, all jobs for the printer will be cancelled. If you are root and want to remove all the jobs belonging to a specific user, specify the user's name. 3.1.8 The `lpc' Command ----------------------- The `lpc' command lets you check the status of printers and control some aspects of their use. In particular it lets you start and stop despooling on printers, lets you enable or disable printers and lets you rearrange the order of jobs in a print queue. The following commands disable printing on myprinter, enable the spool queue on yourprinter and move job number 37 to the top of the queue: lpc down myprinter lpc enable yourprinter lpc topq 37 If invoked without any command arguments, lpc will be interactive, prompting you for actions to take. Read the man page for complete instructions. Bear in mind that some `lpc' functions are restricted to root. 3.1.9 The Important Directories ------------------------------- There is really only one important directory - the spool area where data to be printed is accumulated before `/etc/lpd' prints it. However, typically a system will be set up with multiple spool directories, one for each printer. This makes printer management easier. My system is set up to use `/usr/spool/lpd' as the main spool area, with each separate printer having a directory under that with the same name as the printer. Thus I have a printer called `ps_nff' which has `/usr/spool/lpd/ps_nff' as its spool directory and so on. The spool directories should belong to the daemon group and be user and group read/writable, and world -readable. That is, after creating the directory make sure it has permissions "-rwxrwxr-x" (0775). For the directory myprinter, the appropriate command would be: chmod ug=rwx,o=rx myprinter chgrp daemon myprinter (The locations, ownerships and permissions given here are a simplification and may be wrong for your system *note lpd files and permissions.) 3.1.10 The Important Files -------------------------- Apart from the programs discussed above, each spool directory should contain four files - `.seq', `errs'. `lock' and `status'. These files should have the permissions "-rw-rw-r-". The `.seq' file contains the job number counter for `lpr' to assign a and the `status' file contains the message to be reported by `lpc stat'. The `lock' file is used by `lpd' to prevent itself trying to print two jobs to the same printer at once, and the `errs' file is a log of printer failures. The file `errs' is not required and can actually be called whatever you like - the name is specified in `/etc/printcap', but the file must exist for `lpd' to be able to log to it, so it is usually created manually when setting up the spool area. More on this later. One very important file is the file `/etc/printcap', which is described in detail in the following sections. 3.1.11 More About /etc/printcap ------------------------------- The file `/etc/printcap' is a text file, which may be edited with your favourite editor. It should be owned by root and have the permissions "-rw-r-r-". The contents of `/etc/printcap' are typically very cryptic-looking, but once you know how it works they are much easier to understand. The problem is compounded by the fact that in some braindead distributions there is no man page for printcap, and the fact that most printcaps are created either by programs or by people with no thought for readability. For your own sanity, I recommend making the layout of your printcap file as logical and readable as possible, with lots of comments. And get the a man page from the lpd sources, if you don't already have it. One printcap entry describes one printer. Essentially a printcap entry provides a logical name for a physical device, then describes how data to be sent to that device is to be handled. For example, a printcap entry will define what physical device is to be used, what spool directory data for that device should be stored in, what preprocessing should be performed on the data, where errors on the physical device should be logged and so forth. You can limit the amount of data which may be sent in a single job, or limit access to a printer to certain classes of user. It is perfectly OK to have multiple printcap entries defining several different ways to handle data destined for the same physical printer. For example, a physical printer may support both PostScript and HP Laserjet data formats, depending on some setup sequence being sent to the physical printer before each job. It would make sense to define two printers, one of which preprocesses the data by prepending the HP LaserJet sequence while the other prepends the PostScript sequence. Programs which generate HP data would send it to the HP printer, while programs generating PostScript would print to the PostScript printer. Programs which change the data before it is sent to the physical printer are called "filters". It is possible for a filter to send no data at all to a physical printer. See Also: The Syntax of /etc/printcap # Sample printcap entry with two aliases myprinter|laserwriter:\ # lp is the device to print to - here the first parallel printer. :lp=/dev/lp0: \ # sd means 'spool directory' - where print data is collected :sd=/usr/spool/lpd/myprinter: 3.1.12 Fields in `/etc/printcap' -------------------------------- There are too many fields to describe here in full, so I'll just describe the most important ones. All fields in `/etc/printcap' (except for the names of the printer) are enclosed between a pair of colons and are denoted by a two-letter code. The two-letter code is followed by a value that depends on the type of field. There are three types of field - string, boolean and numeric See Also: The Syntax of /etc/printcap. The following fields are the most common and most important ones: lp string specify the device to print to, eg /dev/lp0 sd string specify the name of the spool directory for this printer lf string specify the file to which errors on this printer are to be logged if string specify the input filter name rm string specify the name of a remote printing host rp string specify the name of a remote printer sh boolean specify this to suppress headers (banner pages) sf boolean specify this to suppress end-of-job form feeds mx numeric specify the maximum allowable print job size (in blocks) 3.1.13 More on The `lp' Field ----------------------------- If you specify `/dev/null' as the print device, all other processing will be performed correctly, but the final data will go to the bit bucket. This is rarely useful except for test printer configurations or with weird printers See Also: Printers not in /dev. When you are setting up a remote printer (that is, you have specified `rm' and `rp' fields), you should specify `:lp=:'. Don't leave the field empty unless you are using a remote printer. The printer daemon will complain if you don't specify a print device. 3.1.14 More On The lf Field --------------------------- Whatever file you specify should already exist, or logging will not occur. 3.1.15 More On The if Field --------------------------- Input filters are programs which take print data on their standard input and generate output on their standard output. A typical use of an input filter is to detect plain text and convert it into PostScript. That is, raw text is its input, PostScript is its output. See Also: Writing lpd filters. When you specify an input filter, the printer daemon does *not* send the spooled print data to the specified device. Instead, it runs the input filter with the spooled data as standard input and the print device as standard output. (For another use for input filters *note A test printcap entry.). 3.1.16 More On The `rm' and `rp' Fields --------------------------------------- Sending your print data to a printer attached to another machine is as simple as specifying the remote machine `rm' and the remote printer `rp', and making sure that the print device field `lp' is empty. Note that data will still be spooled locally before being transferred to the remote machine, and any input filters you specify will be run also. 3.1.17 More On The `sh' and `sf' Fields --------------------------------------- Unless you have a lot of different people using your printer, you will most likely not be interested in banner pages. Suppressing form feeds is most useful if your printer is typically used for output from wordprocessing packages. Most WP packages create complete pages of data, so if the printer daemon is adding a form feed to the end of each job, you will get a blank page after each job. If the printer is usually used for program or directory listings, however, having that form feed ensures that the final page is completely ejected, so each listing starts at the top of a new page. This is Info file Printing-HOWTO.info, produced by Makeinfo-1.55 from the input file printing.texinfo. A guide to printing and previewing files under the Linux operating system. Copyright (C) 1994 by Grant Taylor and Brian McCauley 3.1.18 More On The `mx' Field ----------------------------- This field allows you to limit the size of the print data to be spooled. The number you specify is in BUFSIZE blocks (1K under Linux). If you specify zero, the limit is removed, allowing print jobs to be limited only by available disk space. Note that the limit is on the size of the spooled data, *not* the amount of data sent to the physical printer. If a user tries to exceed this limit the file is tuncated. The user will see a message saying "lpr: : copy file is too large". For text physical printers, this is useful if you have users or programs that may deliberately or accidentally create excessively large output, but in most cases is not really very applicable. For PostScript physical printers, the limit is not useful at all, because a very small amount of spooled PostScript data can generate a large number of output pages. 3.1.19 A Test Printcap Entry ---------------------------- The following shell script is a very simple input filter - it simply concatenates its input onto the end of a file in `/tmp' after an appropriate banner. We specify this filter in our printcap entry and specify `/dev/null' as the print device. The print device will never actually be used, but we have to set it to something because otherwise the printer daemon will complain. #!/bin/sh # This file should be placed in the printer's spool directory and # named input_filter. It should be owned by root, group daemon, and be # world executable (-rwxr-xr-x). echo ------------------------------------------------ >> /tmp/testlp.out date >> /tmp/testlp.out echo ------------------------------------------------ >> /tmp/testlp.out cat >> /tmp/testlp.out Here's the printcap entry. Notice the (reasonably) readable format and the use of continuation characters on all but the last line: myprinter|myprinter: \ :lp=/dev/null: \ :sd=/usr/spool/lpd/myprinter: \ :lf=/usr/spool/lpd/myprinter/errs: \ :if=/usr/spool/lpd/myprinter/input_filter: \ :mx#0: \ :sh: \ :sf: 3.1.20 Putting It All Together ------------------------------ Putting all the above bits together, here is a step by step guide to setting up a single printer on `/dev/lp0'. You can then extend this to other printers. You have to be root do do all this, by the way. 1. Check the permissions and locations of `lpr', `lprm', `lpc', `lpq' and `lpd' See Also: The important programs. 2. Create the spool directory for your printer, which we will call `myprinter' for now. Make sure both are owned by root, group daemon, and are user and group writeable, readonly for others (-rwxrwxr-x). mkdir /usr/spool/lpd /usr/spool/lpd/myprinter chown root.daemon /usr/spool/lpd /usr/spool/lpd/myprinter chmod ug=rwx,o=rx /usr/spool/lpd /usr/spool/lpd/myprinter 3. In the directory `/usr/spool/lpd/myprinter', create the necessary files and give them the correct permissions and owner: cd /usr/spool/lpd/myprinter touch .seq errs status lock chown root.daemon .seq errs status lock chmod ug=rw,o=r .seq errs status lock 4. Create the shell script input_filter in the directory `/usr/spool/lpd/myprinter'. Use the input filter given above. Make sure that the file is owned by root, group daemon, and is executable by anyone. cd /usr/spool/lpd/myprinter chmod ug=rwx,o=rx input_filter 5. Create the file `/etc/printcap' if it doesn't already exist. Remove all entries in it and add the test printcap entry given above. Make sure the file is owned by root, and readonly to everyone else (-rw-r-r-). 6. Edit the file `rc.local'. Add the line `/etc/lpd' to the end. This will run the printer daemon each time the system boots. It is not necessary to boot now though - just run it by hand: lpd 7. Do a test print: ls -l | lpr -Pmyprinter 8. Look in `/tmp' for a file called `testlp.out' - it should contain your directory listing. 9. Edit `/etc/printcap'. Copy the myprinter entry, so you have two identical entries. * in the *first* entry, change both occurrences of `myprinter' to `testlp' in the first line only * in the *second* entry, change `/dev/null' to your real print device, eg., `/dev/lp0' * in the *second* entry, remove the `if' line completely 10. Either reboot the system or kill the printer daemon and restart it. This is because the printer daemon only looks at the /etc/printcap file when it first starts up. 11. Do a test print again - this one should come out on your physical printer! ls -l | lpr -Pmyprinter 3.1.21 More On Remote Printing ------------------------------ In order for any other machines to print using your printers, their names will have to be registered in either the file `/etc/hosts.equiv' or `/etc/hosts.lpd'. These are simple text files, one host name per line. For preference, add hosts to `/etc/hosts.lpd'. `/etc/hosts.equiv' is used to give far wider access rights, and should be avoided wherever possible. You can restrict remote users either by group name (specify the groups permitted using one or more rg fields in `/etc/printcap' - `:rg=admin:' will restrict access to a printer to those users belonging to the group admin. You can also restrict access to those users with accounts on your system, by specifying the boolean flag `:rs:' in your `/etc/printcap'. 3.1.22 The Fiddly Bits ---------------------- If all the above worked, you will now have two printers defined in `/etc/printcap' - one called testlp, which appends output to `/tmp/testlp.out', and one called myprinter which sends unmodified output to the physical printer attached to `/dev/lp0'. Both share the same spool directory. As an exercise, you might like to set up a separate spool directory for the testlp printer. If your printer is a PostScript printer, it may not be able to handle plain text. If this is the case, you'll need to set up a filter to convert plain text to PostScript. An excellent freeware program called nenscript is available which does just this. See Also: PostScript. If you don't set up such a filter, you will have to make sure by other means that the printer is sent only PostScript. You may like to add a line to your login script - or even to the default user login script - which sets up a `PRINTER' environment variable. Under bash, a suitable line would be `export PRINTER=myprinter'. This will prevent people having to specify `-Pmyprinter' every time they submit a print job. To add more printers, just repeat the above process with different printer names. Remember you can have multiple printcap entries all using the same physical device. This lets you treat the same device differently, depending on what you call it when you submit a print job to it. It is possible to "reuse" a printcap entry. If you specify your own machine as the remote host and another printer in your printcap file as the remote printer, you can effectively redirect print data from one printer to another. Remember if you use this technique that all the data will be processed by all input filters in the chain and spooled for each printer it goes through. Although you can specify as many aliases for a printer as you like, it seems that for maximum usefulness the first two should be the same and should be the "real" printer name. Many programs will only ever use one of these two aliases. The `lpc' command will only report on the first alias, though `lpc', `lpr', `lprm' and `lpq' all understand any alias. Rather than specify a maximum spool file size, you may want instead to prevent spool files expanding to fill your disk, even temporarily. To do so, put a file called minfree in each spool directory, specifying the amount of disk space that must remain for spooling data to be accepted. This file is a simple text file, containing the number of blocks to be left free. Usually this file is a link to a file in the main spool directory, as it is rare for different printers to have different minimums. 3.1.23 Troubleshooting ---------------------- Problem: You get a message saying "lpd: connect: No such file or directory" Answer: The printer daemon `/etc/lpd' is not running. You may have forgotten to add it to your `/etc/rc.local' file. Alternatively you did add it, but haven't booted since. Add it and reboot, OR just run /etc/lpd. Remember you have to be root to do this. See Also: lpd not working. Problem: You get a message saying "Job queued, but cannot start daemon". Answer: This often appears right after the "lpd: connect" message. Same problem. Problem: You get a message saying "lpd: cannot create /.seq". Answer: You have not created the spool directory specified in the printcap entry or have misnamed it. An alternative (though much less likely) answer is that you have too little disk space left. Problem: You get a message saying "lpr: Printer queue is disabled". Answer: As root, use `lpc enable ' to enable the printer. Note that as root, you can submit jobs even to a disabled printer. Problem: You submit a print job, there are no error messages, but nothing comes out on the physical printer. Answer: There could be many reasons. Make sure the physical printer is switched on, selected, and physically connected to the device specified in the `/etc/printcap' file. Use the `lpq' command to see whether the entry is in the queue. If it is, then the device may be busy, the printer may be down, or there may be an error on the printer. Check the error log specified in the printcap entry for clues. You can use the `lpc status' command to check whether the printer is down and `lpc up ' to bring it back up if it is (you need to be root to do this). If after checking as suggested your print jobs still do not come out, double check that any input filter you have specified is present in the correct directory and has the correct permissions. If you are running syslogd, you can look in your logs for messages from lpd. If you see log entries saying "cannot execv ", then this is almost certainly the problem. Another possibility is that your printer is a PostScript printer and you are not sending PostScript to it. Most PostScript printers will ignore non-PostScript data. You may need to install an appropriate text-to-PostScript input filter. Lastly (and you'll feel really silly if this is the cause!) check that your input filter actually generates output and that the output device is not `/dev/null'. Problem: When remote printing, your jobs go into the remote queue but never get physically printed. Answer: If you can, look at the entry for the remote printer in the `/etc/printcap' file on the remote machine. It may be restricting your access. The `rg' field restricts access to members of a specific group which you may not be in, and the `rs' field prevents access from users without accounts on the remote machine, which you may not have. Alternatively the printer on the remote machine may have been downed by the system administrator. See Also: lpr over a network. [End of Part 1/2]