A: The Makefile is only used for installing apsfilter within the environment of the FreeBSD ports collection . Other operating systems have packaging utilities of their own to create ``easy to install'' apsfilter packages.

If you downloaded apsfilter yourself without the help of such a OS specific packaging system, then simply extract the apsfilter tar archive in a destination directory of your choice (typically /usr/local/share/apsfilter) and run ./SETUP to create printers.

    root# cd /usr/local/share
    root# tar xvzf apsfilter-x.y.z.tar.gz
    root# cd apsfilter
    root# ./SETUP

Quite easy, isn't it ? ;-)

A: Don't do that then ;-) The script is just for use as lineprinter input filter as part of the line printer scheduler (lpd or LPRng). You only need to type

    lpr filename

to print a file on printers that have been installed by SETUP and apsfilter is automatically executed by the lineprinter scheduler.

A: First, install an arbitrary printer. Remember the queue name you enter for the ``auto'' printer during SETUP.

Then edit /etc/apsfilter/QUEUE/apsfilterrc (replace QUEUE by the queue name mentioned above). Change the line PRINTER=... to the gs-device of your printer. For special options you may have to set GS_FEATURES to contain the features you want.

Be sure that gs can handle your device and options!

A: Solaris is a SYSVR4 based system, and as such it uses a spooling system that doesn't work with apsfilter (and vice versa).

The solution is to remove Solaris own printer spooler subsystem and then to install LPRng, which is supported by apsfilter.

Since LPRng offers many cool features and is more secure than plain BSD lpr spoolers, this step is ``kind of'' recommended anyway.

A: That (virtual) printer passes all input unmodified. If you have some network environment that you want to use the printer in, or you want to access the printer directly for fast ASCII text, you should choose to install that printer.

Since you can run SETUP more than once in order to create multiple printcap entries for the same `` physical'' printer with different defaults (other print resolution, although this is handled more clever by the new `` CLASS support''), its not advisable to install multiple `` raw'' printers.

Therefore you can skip creating raw printer entries for any further ``virtual printer ''.

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.

A: Grab your printer documentation to look for the escape sequences needed. Enter these into the configuration variables RAW_PROLOGUE and RAW_EPILOGUE resp. (remember to use octal values).

E.g. for a printer reset that consists of "ESC c":

    RAW_PROLOGUE='\033c'

An extra formfeed at the end would be enabled by:

    RAW_EPILOGUE='\014'

A: If you use a2ps (default) or mpage to print ASCII text, it first gets translated to PostScript and then rastered by ghostscript; actually you're printing a bitmap in this case.

Edit the appropriate apsfilterrc file to include "ASCII_FILTER=recode" (and be sure to have recode installed). You may also need to set RECODE_OPTS to use the right conversion (default: latin1 to ibmpc).

After that ASCII files will directly be sent to the printer, without any conversion to PostScript. But you also lose all the spiffy features like borders, headers and multiple pages per sheet.

A: Use

    lpr -C ascii filename

to force treatment of filename as ASCII text.

A: Please fix them. :)

If you use FreeBSD, please use one of the a2ps ports (-letter, -a4, -hpdj).

Otherwise you have to edit the Medium definition in the a2ps config file (probably /usr/local/etc/a2ps.cfg). For example:

    #       name     width height   llx    lly     urx    ury
    Medium: A4stylus   595    842    22     45     566    815
           

The numbers are PostScript points (1pt = 1/72"), for width, height, left, bottom, right and top coordinate of the usable part of the page (where (0,0) is lower left).

In this example the margins are about 0.3" left, 0.625" bottom, 0.4" right and 0.375" top.

A: You have to adjust ghostscript to recognize the proper margins. First of all, print out setup/test.ps -- you'll see a raster around the page. This has a millimeter scale, so beware (1" = 25.4mm).

You should easily see what area you printer can use.

uniprint drivers contain a line '-dupMargins="{ 9.0 39.96 9.0 9.0}" or similar; these are the left, bottom, right, top margins in points (1pt = 1/72"). Other

If not the margins, but the page _offset_ is wrong (the whole page is shifted left/right or up/down), you must measure the distance the inner rectangle of setup/test.ps is shifted to the left/top and get the correction parameter from those values.

The left top corner of the (white) inner rectangle is 20mm from the left/top corner of the page (20mm = 0.7874" = 56.7pt). Let's say the distance of that corner is L from the left edge and T from the top edge; then you get

    X = (20 - L) * 28.35       X = (0.7874 - L) * 72
    Y = (20 - T) * 28.35       Y = (0.7874 - T) * 72
    if units are mm            if units are inches
       

Now add '-dMargins="{X Y}"' to GS_FEATURES in the configuration file.

A: Pages in higher resolutions needs plenty of RAM to be rendered. For some printers the standard amount of memory that is built in is just not enough. The only solution is to lower the resolution (to probably half the amount).

A: This ever-annoying problem only occurs with BSD spoolers which just don't give that much information about a print job to the filter.

Install LPRng, or print just one file at a time, or disable headers.

A: The problem is that dvips doesn't know if the file is in landscape mode or not. You have to explicitely use the ``landscape'' class option to print that file properly:

    lpr -C landscape file.dvi

A: Wrong. For examples, a2ps uses colors to render headers, do pretty- printing etc. These colors look different on a grayscale printer than the gray levels used when COLOR=mono is set.

Additionally, some converters use special algorithms when they are told to produce grayscale output; this might improve the result. They usually run faster in this mode, as well.

A: Yes it is. That's why it is disabled by default.

That file is a shell script which gets sourced if the administrator allows this kind of configuration. This is done while running the filter, i.e. under the same user and group IDs, which are frequently privileged users/groups such as root, daemon, lp or bin.

A: Of course:

• check your console (if available: your xconsole) for any error reports

• search /var/log/messages etc. for lpd errors

• enable verbose mode of client programs like lpr, lpq etc.

• enable debugging mode of apsfilter

To debug apsfilter, edit /etc/apsfilter/basedir/bin/apsfilter and remove the comment sign before ``#set -x''.

You might want to save paper while debugging; move to the end of the script and uncomment the three lines in the DEBUG sections.

After the next (failed) printing attempt there's lots of output in the log file (a.k.a. status file) which is located in the printer specific spool dir (see the ``:lf=...:'' line in /etc/printcap).