Postscrip Printer Problems - SUMMARY

Date: Thu Nov 01 1990 - 06:40:35 CST


        Hi I Hope You Can Help
        I have a whole host of printer problems
                an AppleLaserWriter II connected to a sun 3/60 SunOS4.1
                ( printcap files at end )

        1) If I send a large file 2Mbytes+ from a remote machine to the printer
           only about the first 1MByte comes out. I have checked and the same file
           comes out ok if sent from the machine the printer is actually connected
           to. Is There a limit to how big a file lpr/lpd can handle accross the

        2) If More than one file gets into the print queue the only the first
           comes out untill the queue is cleared. What I think is happening here
           is that I can't get rid of the header page. If I put the header first
           then nothing ever comes out, so it goes last. I tell lpr that I don't
           want any headers.

        3) how does one get printer accounting to work ?

        I have read the manuals, tried various different ways but none seem to
        cure my problems. I will summarise to the list if I get any good

I received one very generous offer of help by phone, Thanks.
        Dave Plummer <>


I have included the best replies and a list of all people who replied.
Thanks for all the help. I think I have it working now.

Some people had similar problems, I suggest they read these summiries

>You have to use symbolic links (i.e. lpr -s ye_olde_filename) since lpr
>won't spool a file greater than 1MB (in the lpr man page).
>For problem 2, it sounds like something isn't generating a showpage in
>the postscript file (i.e. look and see if its at the end of the file).

>Mike Rembis <>
>Rick Feeney
        all sugested a similar thing

This was a common answer. If you actually have enough room in your spool
directories to fit all the files then this is not actually a something you
need to do. It is very difficult to get this symbolic link solution to work
when a package is calling lpr directly and you have no control over wether
it uses to -s flag. However given the correct problem I am sure this works.

>Manual comments: (from lpr)
> -h Suppress printing the burst page.
>Henrik Janum

This has the same problems as mentioned above.

>You need to have a :mx#0: item in the printcap entry on every machine
>the file passes through -- so make sure it's there on the clients as
>well as the printer server. This may affect your "hosed until the
>queue clears" problem. As for setting up printer accounting: that's
>the responsibility of the :if=...: program; yours apparently came from
>Interleaf, so check your Interleaf manuals.

>brian kennedy
>Jay Lessert {ogicse,sun,decwrl}!bit!jayl
>Caleb Hess <>
>frew <(Jim Frew)>
>Marke Clinger marke@solbourne.COM
>Michael A. Thompson mike@iotek.uucp
>Tony Tran <>
>Tad Guy <>
>Mark Plumbley <>
        all sugested a similar thing

This cured problem one for us (remember we have about 20Mbytes avaliable for
spooling directories (about 5->20 files))


I received some usefull help but I will sumarise first.
To print postscript sucessfully you need to stop the header pages created
by lpr. This is acheived by using the "sh" entry in printcap. There may or
may not be an unwanted interaction with "hl" & "sb" so it is best to leave these
unset. This helped, but did not cure it. Next we tried sending a <control-D>
using the "tr" option. This was intended to tell the printer that there is not
any more in this document so don't sit there waiting for it. This worked fine
when the queue empties and then someone immediatly sends a new document, but
the "tr" is only sent when the queue empties. We are now using the "fo" and
"ff" options to send a <control-D> when the device is opended (finishing
the previous document). This appears to work. (see end for printcap files).

I haven't tested all possibilities, like sending a load of garbage postsript
and seeing what happens.
The following people gave me some good pointers.
>Steve Riley pacacc!steve@sacto.West.Sun.COM


I havn't had time to try these out, but there are the replys

>Saul Jaffe
>This is a tricky one and totally undocumented anywhere I've seen. I
>have found that you need to do several things to get accounting to
>work besides specifying the account file in the printcap entry.
>First, you need to make sure that all of the programs are running in
>group daemon. (If you don't do this, you will have other insidious
>problems like processes that don't go away when lpd sends a kill
>siganal.) Then, you need to make sure that the accounting files are
>owner daemon, group daemon and read/write by owner and group. If
>your low level filters are all doing accounting, this should work.

>Tad Guy <>
>set :af=: to something, create the file, chown root.daemon, chmod 664

>Charles <>
>From the printcap man pageL
> The am field can take several values with different meanings,
> corresponding to the method of accounting used by the
> machine with that printer. If the field is missing or is 0,
> then no accounting information is passed to the machine. If
> the value is 1, then the gid (group number) of the user
> issuing the print request is sent. If the value is any
> other positive number, then the gid modulo that number is
> sent. (note: the 'af' option should also be set).

>Mark Plumbley <>
>The input/dvi/etc. filter is given the name of the accounting file, if
>one is specified, as one of its arguments (see System & Network Admin -
>but you probably knew that already). I couldn't find anywhere that the
>account file format was specified, either. By experimenting with
>pac(8), it seems that the following account file format should be used:
> pages|feet [hostname:]user [copies]
>10 mdp # 10 pages printed by user mdp
>1 dsl:mdp 5 # 5 copies of 1 page, printed by mdp from machine dsl
>3.5 wolf:root # 3.5 (feet) printed by root on wolf.
>(without the #... comments). The printer filter should add one line
>every print job, with `pac -s' run every so often to clear out the file
>into an accumulated summary, <account_file>_sum. This is the theory -
>I haven't tried it in anger, though.
>I use `lwp' to talk to the our laserwriter - its part of LWkit, FTP'd
>from Trouble is, it uses its own dbm(3)-based accounting
>files, incompatible with pac(8)...

Thanks for all your help. Sorry the summary took so long.
Rick Dipper

/etc/printcap ON MBSUNF, printer conected here on /dev/ttyb
# interleaf internal fonts printer
        :printerleaf=/interleaf/tps4.0/sysio/ps/pl2ps -T cx %! /usr/ucb/lpr -Plaserwriter -h:\
        :other=/usr/ucb/lpr -Plaserwriter -h:
# Apple Laserwriter ][


/etc/printcap ON MACHINE MBSUNC
# interleaf internal fonts printer, VIA MBSUNF


# laserwriter via SUNF


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT