Bug 56871
| Summary: | lack of working filter support for HP2200 at PCL level. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Pawel Salek <pawsa> | ||||
| Component: | foomatic | Assignee: | Tim Waugh <twaugh> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.2 | CC: | djuran | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2002-01-23 14:24:15 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
There is a bug in: /usr/share/foomatic/db/source/driver/lj5mono.xml The <prototype> element is empty. Replacing it with the value taken from lj5gray.xml produces a printout BUT duplex printing flag is IGNORED. Are these reports read? (Yes, they are, but my predecessor apparently didn't spend enough time on it..) This might be related to bug #55909. Yes, the failing ljet4 driver is same in both cases (#55909 contains reports for one driver only). Do the packages at <ftp://people.redhat.com/twaugh/errata-candidate/> help? The updated packages fix the ljet4 filter failure (i.e the filter log claims tha t filtering was successfully finished). I cannot tell anything about other filters, whether anything was physically printed or whether the print quality is OK yet because I am physically away 600km from the printer. I will return with this information within 24h. I asked a collegue to send some test print jobs to jetdirect queues driven by
a). ljet4
b). pxlmono
The filtering is claimed to be successful (I can quote the lpq -vv output here
if it would be useful) but the printer does not print (which suggests that the
change does not improve pxlmono case).
I can investigate closer when I am physically located next to the printer (10
days from now). Currently, I can run only "binary" test via my collegues ("try
printing this file and tell me what you got").
Have in mind that at least ljet4 does not have the dummy configuration error it
used to have.
When did pxlmono last work? I do _not_ remember times when pxlmono worked. The filtering always seemed to be OK but the printer never printed anything. I know it is weird. I should probably try to eliminate network/jetdirectprint out of the equation any try to drive the printer via parallel cable when I come back. (OTOH, printing postscript Level-2 directly to the printer via jetdirectprint works). How about sending it through ghostscript's pxlmono driver? Do you mean gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=pxlmono -sOutputFile=output.pcl6 test.ps && lpr output.pcl6 ? I was hoping it could be piped to jetdirectprint. I'm trying to eliminate the perl hackery; here is the pxlmono driver command line template: gs -q -dBATCH -dSAFER -dNOPAUSE%B%A%Z -sOutputFile=- - | perl -p -e "s/\xc0.\xf8\x26/\xc0%E\xf8\x26/g" In this context, %E is '\x01', and %B%A%Z becomes (I assume) '-sDEVICE=pxlmono'. The perl script is an obvious suspect for corruption. Following combination gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=pxlmono -sOutputFile=- test.ps | perl -p -e 's/\xc0.\xf8\x26/\xc01\xf8\x26/g' | /usr/share/printconf/util/jetdirectprint gives a printout (finally!). But: the perl appears to be a cause for a warning page: PCL XL error Warning: IllegalMediaSource (that's what I got reported. When perl was removed from the pipe, no warning was produced). The perl should read 's/\xc0.\xf8\x26/\xc0\x01\xf8\x26/g'. Right. This one lead to the printout, no warnings at all. The question is, why this does not work when put together. The lpq log says: Status: IF filter 'mf_wrapper' filter msg - 'foomatic-gswrapper: gs '-dBATCH' '-dSAFER' '-dNOPAUSE' '-sDEVICE=pxlmono' '-r600x600' '-sOutputFile=|cat >&3' '-' 3>&1 1>&2' at 11:12:57.679 Should it not be '-sOutputFile=-'? -pawel It is correct as it reads: /usr/bin/foomatic-gswrapper is trying to get the
output on a different file descriptor so that errors (originally dumped to
stdout) can be useful. One thing that has been changed about this in CVS is
to remove the space, so that the line in /usr/bin/foomatic-gswrapper reads:
$_ = '-sOutputFile=|cat>&3'; # quoted properly below...
You could try making that change to see if it makes things any better. The
other difference of course is '-r600x600'.
I did the recommended change but filter prints noting. I continued testing to discover what actually gets send to jetdirectprint and set lp=/tmp/printeroutput.lp in /etc/printcap. It turns out, that only some header is sent to the file, actual content gets lost: -- cut here -- ESC%-12345X@PJL JOB NAME="LPDOMATIC" @PJL SET MANUALFEED=OFF @PJL SET DUPLEX=ON @PJL SET BINDING=LONGEDGE @PJL SET RET=MEDIUM @PJL SET DENSITY=3 @PJL SET COPIES=1 @PJL SET ECONOMODE=OFF @PJL SET BITSPERPIXEL=1 ESC%-12345X@PJL RESET @PJL EOJ -- cut here-- Can you show me the log file from the spool directory when this happens? The ghostscript output should appear before the 'RESET' line. That was actually a great idea to look into the spool directory. There is a file in the spool directory called, guess, |cat>&3 containing the PCL printout. I attach the status file anyway. Created attachment 43294 [details]
log file
Aha. What about if you change '|cat>&3' into '/dev/fd/3', like this?:
$_ = '-sOutputFile=/dev/fd/3'; # quoted properly below...
$_ = '-sOutputFile=/dev/fd/3'; # quoted properly below... appears to be the solution. Okay, I've incorporated that fix into foomatic-1.1-0.20011218.1.5 at <ftp://people.redhat.com/twaugh/errata-candidate/>. I got the bug number wrong in the changelog; I'll fix that before the errata is issued. Fixed in RHBA-2001:174. Great job done! Thanks. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: Support of HP2200 seems to be a POS as of foomatic-1.1-0.20011018.3. The only reliably working filter is Postscript. All other drivers (lj5gray, lj5mono, ljet4, pxlmono) have problems with internal relability (I do not mean gs problems). Version-Release number of selected component (if applicable): foomatic-1.1-0.20011018.3 How reproducible: Always Steps to Reproduce: 1. use printconf-gui to configure the printer HP/HP LaserJet 2200 as JETDIRECT. 2. select the drivers in the sequence (postscript, lj5gray,lj5mono,ljet4,pxlmono). 3. watch strange things happen. Actual Results: postscript actually works as long as the interpreter does not run out of memory (but this is a printer problem). lj5gray is much slower than postscript(!). OK, this is probably not filter problem, but gs. lj5mono fail because lpdomatic has problems itself or with provided configuration: /usr/sbin/lpdomatic: running: ' at 11:26:13.514 /usr/sbin/lpdomatic: postscript job line1=>%!PS-Adobe-3.0' at 11:26:14.098 <' at 11:26:14.098 gs PID pid2=7454' at 11:26:14.099 Couldn't exec at /usr/sbin/lpdomatic line 629.' at 11:26:14.101 tail process done writing data to *main::STDOUT' at 11:26:14.107 Note that $commandline==''(!). ljet4 fails with: 'mf_wrapper' filter msg - 'closing *main::KID3' at 11:37:17.848 'mf_wrapper' filter msg - 'Error closing pipe to gs -q -dBATCH -dSAFER -dNOPAUSE -sDEVICE=ljet4 -sOutputFile=- - | perl -e "my \$a = join('', <>); my \$b = \"\"; \$a =~ s/\x{1b}&l\d+A/\$&\$b/; \$a =~ s/\x{1b}&l0H/\$b/g; print \$a" at /usr/sbin/lpdomatic line 422, <STDIN> line 88531.' at 11:37:17.848 'mf_wrapper' filter exit status 'JFAIL' at 11:37:17.857 pxlmono does not report any problems but prints nothing. Expected Results: The printer should actually print something in a reasonable time. Additional info: Always, the default options were used, with exception for "Binding for double-sideprinting: long edge" which seems like a more reasonable default to me, and "ghostscript prefiltering" set to "PS level 2" to handle poscript level 3 documents (the printer supports level 2 only). Lack of working PCL filters render the printer useless for more complex printouts.