HP networked printer -- hp-setup won't use, hp-probe finds

Gary Aitken freebsd at dreamchaser.org
Sun Jun 3 07:01:13 UTC 2012

On 06/02/12 18:35, Polytropon wrote:
> On Sat, 02 Jun 2012 18:08:55 -0600, Gary Aitken wrote:
>> I've deinstalled cups and its dependencies and rebuilt only hpijs.
> You could have kept it installed (maybe some ports will want
> it as a dependency), just disable it in /etc/rc.conf.

I'm probably going to have to rebuild anyway, as I was totally unclear on what cups was initially and whether or not it was needed / wanted.  One of the problems with not having another system and display when starting out, and not understanding the architecture at first.
>> However, when I try to use gs + hpijs as a filter, it fails.
> Did you write your own filter?

I used a tweaked version of the one Wojciech Puchar just posted,
which appears to be a tweaked version of the one supplied with the hpijs port.
I turned off some of the batch type options to help see what was going on.


#export PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin
export PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/share/ppd

/usr/local/bin/gs -dBATCH -dPARANOIDSAFER -dNOPAUSE \
-sDEVICE=ijs -sIjsServer=hpijs -sDeviceManufacturer="HEWLETT-PACKARD" \
-sDeviceModel="Officejet Pro 8500 A909g" \
-sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=2 \
-sOutputFile=/tmp/$$ - >/dev/null
#-sDeviceModel="DESKJET 960" \
#/usr/local/bin/gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE \
#-sOutputFile=- - && exit 0
cat /tmp/$$
#rm /tmp/$$

> For comparison: I'm using a HP Laserjet 4000 duplex here,
> networked, with /opt/libexec/ps2pcl-dup.sh being the
> filter for use with duplexing:
> #!/bin/sh
> printf "\033&k2G" || exit 2
>          -sDEVICE=ljet4d -dDuplex=true \
>          -sOutputFile=- -&&  exit 0
> exit 2
> The entry for this printer in /etc/printcap is:
> Laserjet|ljet4d;r=600x600;q=high;c=full;p=a4;m=auto:\
>      :rm=\
>      :rp=raw:\
>      :lp=:\
>      :if=/opt/libexec/ps2pcl-dup.sh:\
>      :sd=/var/spool/lpd/Laserjet:\
>      :lf=/var/spool/lpd/Laserjet/log:\
>      :af=/var/spool/lpd/Laserjet/acct:\
>      :mx#0:\
>      :sh:
> The name "Laserjet" is set in $PRINTER as the system's default
> printer. There's also "Laserjet-nodup" where the filter simply
> omits the duplexing functionality.
> I assume you did something similarly?

That's quite a bit different, in that the output device for mine is the ijs daemon with hpijs as the ijs server.  That part's from the hp sample script with the hpijs port.  As you can see from the script and the commented out lines, the "-sDeviceModel=XXX" is what is changing the behavior.  If I swap that one argument, it works.

> Can you provide the command you've used for printing? By default,
> the printer subsystem accepts PS (which is the normal printing
> output format of _any_ printing application).

lpr foo.txt
lpr foo.pdf

>> Also, the ppd.gz files from the port *did not* include any
>> ppd.gz file for this printer.  However, the cups port did,
>> but they were installed elsewhere.  So I just copied them
>> over, but I'm wondering if there is a db or internal cache
>> somewhere that has to be rebuilt.
> The ppd handling tool usually manages that.

I never saw that mentioned.  What's the ppd handling tool?

>> It looks to me like it is unable to locate a .ppd.gz or .ppd
>> which matches the device name "enough" to be used.  Anyone know
>>    who is generating the error
> It's lpd (see message).

I'm not certain about that.  
It may be an error passed up by the ijs subsystem and simply spit out by lpd.

> It's accessing a printer called "lp" (does it exist with tha
> name?) and loses the connection, and try to restart it. The
> inability is expressed as "unable to set device=HP Officejet
> Pro 8500 a909g hpijs", I'm not sure if spaces are allowed?
> (Check "man 5 printcap" to be sure.)

Spaces are allowed; "DESKJET 960" works.
But that name is coming from the :if: script, not printcap.
Again, I don't think it's a printcap / lpr issue.  
lpr is simply running the script it found by looking up device lp.
The script passes the DeviceModel on to gs, 
which feeds it to ijs (-sDEVICE=ijs)
which uses the hpijs implementation
which is what I think is failing to find the ppd file or its contents.
(which I think it has cached, see below; 
I think the actual files are irrelevant at this point)

lpr passes the appropriate stuff to gs,
which creates a file,
which lpr then sends on to the output device :rm=aa.bb.cc.dd:
The gs process gets cut short because hpijs or ijs can't fine the ppd file/contents its looking for,
so the file created by gs is empty 
and the error gets passed on up to lpd
and nothing gets sent to the device.

Here's my printcap entry:

lp|hp|text|hp8500|HP Officejet Pro 8500 a909g:\
>> Ok, I tweeked /etc/printcap and the filter to call the printer
>> a "DESKJET 960" and it worked.
> Is your $PRINTER set to this name? In that case, you could
> easily move from "lp" (the default name) to omitting -P<name>
> in the lp* commands.

$PRINTER is not set
All of the above is dealing with the default printer, lp.
I don't even need to tweak printcap;
the above one works if the :if: script uses -sDeviceModel="DESKJET 960"
The only change is to the "-sDeviceModel=XXX" in the input filter script.

>> So one obviously has to do more than just supply the correct
>> .ppd.gz file in the correct spot.
> Right. If you look into a .ppd file, you'll see PostScript in
> there. 

But I don't think it's even looking at the actual files at this point;
I think they have been cached at install time somehow.

Somebody (I claim gs via the ijs subsystem) is trying to find the contents of the correct .ppd file.  Either by looking
  1. at a dictionary built from the ppd files at install time
     1a. using file names (the installed files are still zipped)
     1b. using their ps contents 
  2. looking at the file names or their ps contents at run time

I claim it's #1, because simply putting the right file in the right place doesn't work, unless I haven't found the right place.  I just tried moving the whole /usr/local/share/ppd directory to another name and it still worked.  There are no other ppd files around at this point.  A daemon could have the file handle open and still get at it, but the ijs daemon is started up and terminated with each print job.

Which is why I'd like to know about this ppd tool if that's what it is.
I need to be able to put the appropriate ppd.gz file in the right place and recreate the cache, wherever / whatever it is.


More information about the freebsd-questions mailing list