cups

[John Baldwin]

On Sunday 02 April 2006 00:33, Jin Guojun [VFFS] wrote:
> Carlos Silva wrote:
> 
> >
> >> my logs from the error are:
> >> ..... (skipped)
> >>  '-dQUIET' '-dNOPAUSE' '-sDEVICE=ijs' '-sIjsServer=hpijs' 
> >> '-sDeviceManufacturer=HEWLETT-PACKARD' '-sDeviceModel=PHOTOSMART 
> >> 1115' '-dDEVICEWIDTHPOINTS=595' '-dDEVICEHEIGHTPOINTS=842' 
> >> '-dDuplex=false' '-r300' 
> >> '-sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=2,PS:MediaPosition=7' 
> >> '-dIjsUseOutputFD' '-sOutputFile=/dev/fd/3' '/dev/fd/0' 3>&1 1>&2
> >
> >> D [25/Mar/2006:23:37:55 +0000] [Job 7] **** Unable to open the 
> >> initial device, quitting.
> >> D [25/Mar/2006:23:37:55 +0000] [Job 7] renderer return value: 1
> >> D [25/Mar/2006:23:37:55 +0000] [Job 7] renderer received signal: 1
> >> D [25/Mar/2006:23:37:55 +0000] [Job 7] tail process done writing data 
> >> to STDOUT
> >
> By looking closely, somewhere in filter configuration (mime.convs?) is 
> messed up.
> 
> clause        '-sOutputFile=/dev/fd/3' '/dev/fd/0' 3>&1 1>&2
> 
> means:    to read data from stdin and send result to stderr (not stdout, 
> weird);

No, /dev/fd/3 is not stderr, /dev/fd/2 is stderr.  It's basically using a
trick to make any messages that gs sends to stdout be sent to stderr
rather than into the file sent to the printer so that the user can see them.
It is doing this by telling gs to write it's output to /dev/fd/3 and
then in the shell telling it to open /dev/fd/3 as a clone of the current
stdout ('3>&1' does this).  It then changes stdout to point to the same
descriptor as stderr ('1>&2').  This seems perfectly fine.

I don't have any ideas on the OP's problem with cups though.  I still
use lpr with apsfilter myself.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org