Re: 7.2.1 great local, bypassed (?) from remote - OS X's lpr

[jon butchar <jbutchar@xxxxxxxxxxxxxxx>]

Hi.

The "%!PS" looked like what I found in the magic file for postscript,
and "file" on my FreeBSD computer saw it as postscript conforming to
level 3.0.

I did the "set -x" and took a quick peek at the lp logfile after a
couple more prints.  It showed that jobs from the iMac were being sent
raw.

Just to see if it might be something with the iMac's way of using lpr, I
commented out the [ "$LPD_METHOD" ] && METHOD="$LPD_METHOD" line in
bin/apsfilter.

The next print job from the iMac worked completely fine, and subsequent
jobs also looked good.  Logs showed that the jobs were now seen /
treated as postscript level 3.0, and gs was invoked.  All OK.

A guess, Mac OS X forces jobs through as "raw" and apsfilter 7.2.1 was
merely obliging?  Did the older 6.1.1 handle this differently?  Anyhow,
it looks like I need to dig into OS X's lpr defaults.

Thanks very much for your help.

jon b





On Mon, 2002-02-04 at 04:09, Michael=?iso-8859-1?Q?_Lo=DFin?= wrote:
> 
> One non-trivial change between those releases was the file type
> recognition routine. While 6.1.1 was rather forgiving, all later
> versions use a more restricted set of file description strings
> that the file(1) command is expected to deliver. (The former
> approach could be fooled too easily.)
> 
> Please save the output from the Mac driver to a file and see what
> your file(1) command on the BSD machine thinks about it.
> If it doesn't start with "PostScript document" (case independent),
> apsfilter doesn't recognize it correctly -- it's probably handled
> like ordinary text. One reason for this could be sending a ^D
> (= \004) character at the beginning (although file-3.37 handles
> that correctly).
> 
> Otherwise we need a full apsfilter log. Add "set -x" at the top
> of .../bin/apsfilter and send us the log or status file (whichever
> your spooler uses).
> 
> 
> HTH
> Michael