Date: Sun, 3 Jun 2012 16:26:42 +0200 From: Polytropon <freebsd@edvax.de> To: freebsd@dreamchaser.org Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: HP networked printer -- hp-setup won't use, hp-probe finds Message-ID: <20120603162642.a8af2417.freebsd@edvax.de> In-Reply-To: <4FCB0BB3.1020203@dreamchaser.org> References: <4FC7F8AE.1010307@dreamchaser.org> <alpine.BSF.2.00.1206021024530.35474@wojtek.tensor.gdynia.pl> <4FCAAB17.2010905@dreamchaser.org> <20120603023552.acd054ac.freebsd@edvax.de> <4FCB0BB3.1020203@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 03 Jun 2012 01:01:07 -0600, Gary Aitken wrote: > 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. As a summary, CUPS is both a replacement of the system's default printer spooler (lpr) and its command line tools (lpr, lpq, lprm, plus lpstat, lpconfig), as well as a collection of printer filters (to turn PS into different printer languages) and preprocessors (to turn non-PS input files into PS prior to printing). It's being considered _the_ standard meanwhile for many "modern" software packages that have "hardcoded expectations" that CUPS is present and running, in order to print (instead of just to submit the PS data to whatever is there - lpr is _always_ there). > One of the problems with not having another system and display > when starting out, and not understanding the architecture at > first. As soon as you've got the the basic system up and running, a minimal windowing environment, some xterms, a MUA and a web browser should be sufficient. > >> 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. > > #!/bin/sh > > #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" \ > -dIjsUseOutputFD -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r600 \ > -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/$$ Ah okay, this uses ijs, _not_ a .ppd file. See the -sDEVICE parameter which is the "main entry" to what printer filter will be used (to compare, in my case it's "ljet4d" which produces PCL that gets then sent). > > 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 > > gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER -sPAPERSIZE=a4 -r600x600 \ > > -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=192.168.100.100:\ > > :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. Correct. If the ijs system supports your printer, it should be fine. > 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. Good! > > 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 For diagnostics, you should always start with a PS file. This is what the printer spooler accepts as input. Before printing, check the PS file with "gv <filename>" to make sure it contains what you expect it to contain. All applications that have a "print to file" option will output PS. In the past, I've been using apsfilter to do the preprocessing (? -> PS), but its backend was the same simple gs command as I'm using today, even the automatically generated printcap entry was similar (except at that time, the printer destination was parallel). > >> 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? CUPS for example. It "integrates" the content of the .ppd file into its printer filtering mechanism. If you supply a .ppd file in the printer configuration, it will use this instead of its own filters (which may not be up to date with all "modern" printers). > >> 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. That is possible. It's hard to judge this more precisely from the logged message. > > 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. Okay, as I've seen from your filter, it's properly quoted. > 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) I'm not sure in how far hpijs utilizes .ppd files (instead of using the filter descriptions bundled in the installation package). The hpijs port installs .ppd files into /usr/local/share/ppd/HP/ which should be the search path, except there's a configuration file saying otherwise. > 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. Sounds logical. > Here's my printcap entry: > > lp|hp|text|hp8500|HP Officejet Pro 8500 a909g:\ > :lp=:\ > :sh:\ > :mx=1000:\ > :rm=aa.bb.cc.dd:\ > :rp=lp:\ > :sd=/var/spool/lpd/hp8500:\ > :lf=/var/log/lpd-errs:\ > :if=/var/spool/lpd/hp8500/diff.2: Well, I see differences to my (working) configuration. First of all, you don't have specified some parameters like r=600x600 or q=high or paper size, which should be no problem. You're specifying rp=lp. Is this the _remote_ name on which the printer can be accessed? I have "rp=raw" which doesn't utilize the printer's _internal_ spooling mechanism. Name and location of your input filter look a bit strange, but if it's available at /var/spool/lpd/hp8500/diff.2, that also should be no problem. By the way, have you tried using your filter directly for testing? As mentioned before, prepare a printable PS file, then do: # cat test.ps | /var/spool/lpd/hp8500/diff.2 | nc 123.45.67.890 Note: nc is from port "nc" (netcat). It will send it directly to the IP address, which will normally be done by lpr, but just for diagnostics, always work with the smallest possible variables. :-) If the printer expects a certain destination port (e. g. as it uses this to "switch between multiple personalities), add the port number after the IP (e. g. "nc 123.45.67.890 1000"). Does _this_ work? > >> 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. Okay, so no problem here. > 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. The printcap file only controls how to convert and where to send the printing data. > >> 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. > > Yep. > 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. That depends on the configuration of the port, maybe it simply parses its PPD source directory at every invocation, or it has a config file dealing with that. > 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 Regarding the naming of the .ppd files, no. 2 sounds possible. > 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. Yes, the hpijs port specifies /usr/local/share/ppd/HP/ which is an addition to what you mentioned. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120603162642.a8af2417.freebsd>