Re: scaling problems with 7.2.1

[Michael Loßin <phallobst@xxxxxx>]

On 06-Feb-02 Shaun Jurrens wrote:
> I upgraded recently from apsfilter 5.2.1 (iirc) to 7.2.1 and since then I
> seem to have some wierd scaling problems.  I'm using the fbsd port and 
> AFPL Ghostscript 7.03 (2001-10-20) on a HP 4L printer.

Did you really change just from 5.2.1 to 7.2.1, or did you also
update ghostscript or some other important package?

> The basic problem appears as huge scaling of printed documents, i.e. a
> printjob from a remote (also 4.5 fbsd) machine from netscape, is printed
> side-by-side on numerous A4 pages.

I have a hard time picturing what you mean here...

Does that apply only to print jobs from Netscape? What happens
if you print to a file (from within netscape) and view that file
in ghostview?

Do the same problems occur when you print directly on the server
machine? Does "aps2file -D ..." give any hints there?

>       strangely enough, I get these errors in the log file, which point to 
>       some parsing error in the apsfilter script:
> 
> apsfilter warning: unknown option 'dakota'
> apsfilter warning: unknown option 'dakota'
> ...
> 
>       bascially one error for each printjob, which come from host "dakota"

That happens if the spooler adds the host name to the "class"
specification (I don't know why or if this is necessary).
But it's just a warning, you can safely ignore it.

> PRINTER='ljet4d'
> PAPERSIZE='a4'
> METHOD='auto'
> QUALITY='high'
> COLOR='mono'
> RESOLUTION='600x600'

I don't know if the "ljet4d" driver is the correct one for the
LaserJet 4L -- the "L" editions are known to be very picky.
Maybe the "gimp-print/stp" driver (or "omni" if you are very
adventurous) can help.

(The fact that gimp-print has separate drivers for the LJ4 and
LJ4L is an indication that you might be using the wrong driver.)

> I've try adjusting resolutions, gray/mono settings, auto/raw setting (raw
> just spits out garbage) and even hacking a little in apsfilter itself, but
> I haven't taken the time to do a lot of debugging "echos" yet, to see why
> it's having problems with the remote printing headers.  I'm using the stock
> fbsd lpd's on both machines.  I've tried running lpd -d on the printer
> "server" and see no errors there.  The outdated info on debugging apsfilter
> (uncomment "#set -x") no longer applies.  I haven't run out of things to
> try yet, but I've done quite a bit, including reading the handbook and FAQ
> and searching the ML archives.  Perhaps someone has an idea here.

You can still add "set -x" in a single at the top of the script,
but I assume that it's rather a ghostscript/driver issue here.


Michael