From: haroldt@paralandra.yorku.ca (Harold Tomlinson)
Subject: Re: line printer deamon for Linux, any suggestions?
Organization: York Computing Services
Date: Mon, 6 Apr 1992 22:57:39 GMT


(Note:: The following is my opinion only and assumes that there is a
future for Linux that involves useful work.  I don't have a copy of
Linux yet and can only share from experience with Ultrix, RiscOs, and
SunOs.) 

:) Now I need a line printer deamon.  I wrote a small deamon with lpd, lpr,
:) lprm and lpq a few months ago for MINIX.  It is a simple deamon, only made
:) for one queue.  I am not familiar with real UNIX printer deamons, I know
:) how to use lpr, lpq and lprm, that's all.

  Have you heard of plpd?  There is a set of programs that are in the
public domain which work slightly better than lpd/lpr/lpq/lpc/lprm/pac.

:) My deamon will be started by lpr and then runs until the queue is empty.
:) When there is nothing to print, no deamon runs and no resources are
:) wasted.  It supports multiple kinds of paper, because I sometimes change
:) between single sheets and endless paper.  It has no priority classes, no
:) net interface, no printcap, no multiple queues with job scheduling or
:) things like that.

  These are nice features.  Do you think it will save that much to
have the daemon die as opposed to having swap out util needed?  What
about the overhead of startup?  *nix "lpd" is not a big resource user.
When started, it reads the /etc/printcap file, then checks the printer
queues listed there (usually /usr/spool/<printername>).  If it runs
out of stuff to print, it goes to sleep for a while.  This usually
gets it swapped out.

:) -  Would you prefer a standard system V deamon?

  Personally, I think you should look at the plpd set.  Perhaps it
will be a small-effort port.

:) -  Do you think a Linux specific deamon with special support for typical
:)    PC problems (multiple kinds of paper etc.) may be better?

  We handle multiple forms with multiple queues, not a great way, but
it works.  The other option is to use the "-C" option and have the
output-filter (see printcap(5)) check for that then send the setup
string to the printer.

:) -  I don't know how printcap works, I only know it is a termcap like
:)    database for printer capabilities.  Do you think it is useful, do you
:)    use it and can you give me more informations about it?

  It's not that difficult.  The manuals with the plpd set helps you to
understand it better.  Yes, it is useful.  Very.  It allows you to
configure the following options:  
(NOTE: IMHO: U=useful, N=not useful, D=doesnt matter, V=vital)

	af	where to keep track of who printed and how much	(D)
	br	set baud rate on serial printer port		(V)
	cf	special filter					(D)
	df	special filter (TeX)				(D)
	dn	binary for printer daemon. (daemon name)	(D)
	du	userid for daemon				(D)
	fc	clear tty flags. ie reset serial line		(U)
	ff	string to use for form feed, ie CR vs CRLF	(U)
	fo	form-feed on open.  send a preceeding ff	(U)
	fs	set tty flags.   ie reset serial line		(U)
	gf	special filter					(D)
	ic	non-standard ioctrl				(D)
	if	input filter - format and print header page	(U)
	lf	where to log errors				(U)
	lo	name of lock file				(D)
	lp	device for printer. /dev/tty01 or whatever	(V)
	mc	maximum copies					(U)
	mx	maximum file size, ensure that /tmp has room	(U)
	nc	remove control characters			(U)
	nf	special filter					(D)
	of	output filter, format document			(U)
	pl	page length					(U)
	pw	page width					(U)
	sb	short banner, one line only			(U)
	sc	supress copies					(U)
	sd	spool directory					(V)
	sf	suppress form feeds				(U)
	sh	suppress banner page				(U)
	st	printer status file name			(U)
	
  There are other options which are even less useful or may not be
relivant to a PC-*nix.

  (I can send you an anotated sample printcap if you want to
understand it.)

:) -  I thought about running the spool files through compress, the printer
:)    is so slow, that uncompressing should not need much CPU power.  Any
:)    comments?

  Usually not benificial, most files are so small they are not worth
compressing.  If they are large enough to warrent compression, you
would be spending a lot of time compressing only to uncompress before
printing.  There is also an option in the standard "-s" option to
lpr which uses symlinks instead of copying the file to the spool
directory.  

:) -  My lpr does not know any filter options.  Do you consider them to be
:)    useful?  Any suggestions, standards on how to implement them?

  Again, check plpd.  Why reinvent the sports car?  Filters are vital.
For example, if you have a postscript printer, you have to use the
"of" in the printcap to specify a filter that will convert the header
page to postscript.  The "of" (output filter) also sends setup
information to the printer if you so desire.  The the rest of the
document should be sent through the "if" (input filter) which can
check to see if it is postscript and convert if needed.

  If you don't use filters, you are assuming the world has the same
printer as you.  

:) -  My lpr does not change the incoming data in any way, no \n to \r\n
:)    expansion, no tab expansion, no line break after a fixed number of
:)    characters etc. Ok?

  Yes.  lpr should not touch the file.  It should only copy it to the
spool directory (if required) and go away.  lpd checks the spool
directories every once in a while to see if there are any files.  lpr
also creates a "control file"  ...

paralandra> l /usr/spool/laser2/
total 11
   1 drwxrwxrwx  2 root          512 Apr  6 17:31 ./
   1 -rw-rw----  1 daemon        103 Apr  6 17:31 cfA075paralandra
   5 -rw-rw----  1 haroldt      4832 Apr  6 17:31 dfA075paralandra
   1 -rw-r-----  1 root            4 Apr  6 17:31 .seq
   1 -rwxr--r--  1 root            4 Apr  2 14:49 lock*
   1 -rw-rw-rw-  1 root           26 Mar  2 16:14 laser2_status
   1 drwxr-xr-x 18 daemon        512 Jan 15 10:53 ../
   0 -rw-rw-rw-  1 root            0 May 15  1991 laser2_log
   0 -rw-rw-rw-  1 root            0 May 15  1991 laser2_acct

  The file beginning with "cf" contains information needed by lpd.  lpd
looks for this file, reads it, and prints to the printer associated
with this dir (from the printcap file).  If there are changes to be
made, it will be by the "of" and/or "if" specified in the printcap.

:) I set the \n -> \r\n menu entry on my printer, so I can print usual text
:) files without converting them.

:) I am waiting for your suggestions, what would you appreciate to see in a
:) line printer deamon package?
:) 
:) Michael


  Again, I'd strongly suggest finding out about plpd.  It seems
confusing at first but is well worth knowing.  If you want the
information I can dig it up and send it to you.

  I don't remember where it came from, nor do I know if there is a
newer version available, but, if nothing else, this information will
help you to understand the lpd suite.  Please do, it would help.  

--
# Harold Tomlinson			##	haroldt@paralandra.yorku.ca #
# Computing & Communications Services	##	(416)736-5257-33802         #
# YORK UNIVERSITY, Ont, CANADA		##	########################### #

Newsgroups: comp.os.linux