Chapter 2. Printing Errors

A: SETUP alters the line printer schedulers (lpd, LPRng) configuration file /etc/printcap, so you have to tell the daemon to use the new configuration.

For LPRng use:

    lpc reread

For Berkeley-style lpd use:

    lpc restart all

alternatively use the vendor-specific init script

    /etc/rc.d/init.d/lpd restart

Please note, paths and names are OS specific.

A: First of all, try this answer .

If that doesn't work, enable debugging in the apsfilter script .

If the output in the logfile (see :lf=...: in /etc/printcap) doesn't help you, have a look at HOWTO-BUGREPORTS, which can be found in the apsfilter installation directory.

A: In this case you must use a ``fake'' printer that just does the filtering.

Install a normal local printer with SETUP. Then create a new file /etc/apsfilter/QUEUE/lpr.conf (substitute QUEUE for the queue name you entered during SETUP) that just has one line in it:

       REMOTE_NAME=insert_the_real_remote_printer_name_here

Then edit /etc/printcap and change the entry for the given printer so that it says

       :lp=/dev/null:\

instead of what you entered as the local device in SETUP. Restart the daemon (see here) ) and you should be set!

A: By default apsfilter uses a restricted PATH for security reasons. You can alter the PATH in /etc/apsfilterrc (global) or in the printer specific apsfilterrc.

A: Unfortunately there are different versions of dvips available with different command line options, some use ``-P'' some ``-D''.

The default is ``-D'', so you want to edit /etc/apsfilterrc now to use ``-P''.

A: It might even be there, but the filter needs to know where it is. For BSD-style spoolers (not LPRng) the only chance to get this information is to look at the accounting file name, which normally is placed within the spool dir.

So do not remove the ``:af=...: line'' in /etc/printcap, it is really needed!

A: You are referring to the control file (cf...) which must be parsed to get some information about the print job when a BSD spooler is used.

This file apparently is created with the wrong owner/group and/or with too restrictive read permissions.

Actually, your distributor didn't do his job well. Get around this problem by reinstalling lpd or LPRng.

A: The pstools need properly created PostScript files to process them the way you want. They have to follow the DSC (Document Structuring Conventions) so that they can be handled.

Please try the fixps tool (or some variant) on your input file to get it working.

A: That depends on the file format and the way the images are embedded.

For inline images, i.e. images that are literally included in the file, there shouldn't be any problems.

If the image is referenced by a filename, it must not only be found but it must also be accessible.

Relative pathnames are very hard for the filter to expand, since it must know a directory (or a set of directories) to search in. Absolute pathnames are more pleasant, but you still have to make sure that the referenced file is readable by anyone _and_ every directory down the path is executable by anyone.

The easiest way to print the file correctly might be to convert it to PostScript manually (maybe the application has an export option, otherwise have a look at the script to get a hint what to do) and then print it the usual way.