Bug 257 - printtool's ps-to-printer.fpi catches too much of ghostscript's output
printtool's ps-to-printer.fpi catches too much of ghostscript's output
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rhs-printfilters (Show other bugs)
5.2
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-12-02 01:39 EST by jon
Modified: 2014-03-16 22:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1998-12-29 11:08:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jon 1998-12-02 01:39:23 EST
Sometimes, ghostscript outputs stuff to stdout in addition
to the expected output to the printer.  (Specifically, this
happens when it is interpreting postscript files generated
using MS Windows' print driver)  This leads to distorted
printer output.  The recommended fix is to change the
"we're using ghostscript" section of the ps-to-printer.fpi
file to the following.

#  we're using ghostscript
GSTMPFILE=`mktemp /tmp/printfilter_XXXXXX`

   eval "$mpage_cmd | gs -q -sDEVICE=$GSDEVICE \
      -r$RESOLUTION \
      -sPAPERSIZE=$PAPERSIZE \
      -dNOPAUSE \
      -dSAFER \
      -sOutputFile=$GSTMPFILE \
      $COLOR \
      $EXTRA_GS_OPTIONS \
      - > /dev/null"
   cat $GSTMPFILE
   rm -f $GSTMPFILE
fi


The changes made, in summary, are
1) setting the GSTMPFILE variable using mktemp
2) setting the -sOutputFile parameter of gs to $GSTMPFILE
3) redirecting stdout of gs to /dev/null
4) catting and rm'ing the temp file after running gs.
Comment 1 Bill Nottingham 1998-12-03 17:19:59 EST
Can you mail me (not the bug system) an example of such a printout?
Comment 2 Bill Nottingham 1998-12-29 11:01:59 EST
*** Bug 257 has been marked as a duplicate of this bug. ***

When I try to use this filter, I get the following error
printed:
Unrecoverable error: rangecheck in .putdeviceprops
(1488)op_array(486)0x817b0d4:E

This was with it configured for black and white printing.
My printer is a deskjet 400.  Using the Deskjet 500 driver
seems to be a workaround.


------- Additional Comments From dclark@pobox.com  12/05/98 13:11 -------
I get the same error using the "HP 550C/450C/6xxC series" driver for
my HP DeskJet 600C printer under RedHat 5.2. I did not have this
problem under 5.1. In addition to the error that is printed out which
is mentioned in the initial bug report, this also comes up on the
console:

stdin: is not a tty/var/spool/lpd/lp/filter: /root/general.cfg: No
such file or directory
/var/spool/lpd/lp/filter: [: asc: unary operator expected
/var/spool/lpd/lp/filter: [: printer: unary operator expected
/var/spool/lpd/lp/filter: [: printer: unary operator expected
/var/spool/lpd/lp/filter: [: ps: unary operator expected
/var/spool/lpd/lp/filter: [: ps: unary operator expected
/var/spool/lpd/lp/filter: [: printer: unary operator expected
/var/spool/lpd/lp/filter: [: printer: unary operator expected

I've tried replacing the rhs-printfilters, ghostscript,
ghostscript-fonts, printtool, and lpr packages with the RH5.1 versions
without success (However I do get different error messages when I do
this).


------- Additional Comments From dclark@pobox.com  12/05/98 14:30 -------
Setting the filter for 2 pagers per output page seems to make this
problem also happen under the "DeskJet 500" driver when printing the
Postscript Test Page. No console messages appear, but the

Unrecoverable error: rangecheck in .putdeviceprops
(1488)op_array(486)0x817b0d4:E

happens.

------- Additional Comments From notting@redhat.com  12/08/98 11:13 -------
Hmm. It appears the cdj550 driver for ghostscript is broken for
1bpp mode. What you can do to work around this is:

- go into the input filter settings in printtool, and set the
  'Color Depth' to 8 for B&W printing.
- use the DeskJet 500 or some other mostly-compatible driver


------- Additional Comments From notting@redhat.com  12/10/98 17:44 -------
*** Bug 288 has been marked as a duplicate of this bug. ***
... at least from netscape. I tried both Netscape 4.05-4
and  (after) I tried Communicator 4.07-1.

I am not sure if the problem is with Netscape or lpr.

I am printing locally and I can print from the command line
just fine. It even spits it out if I print after netscape
chokes on it.

It gives the error:
"Unrecoverable error: rangecheck in .putdeviceprops

(1488)op_arrray(486)0x817b0d4:E" [where it goes off the end
of the page. Also after .putdeviceprops and before (1488)
there is no carriage return]

------- Additional Comments From notting@redhat.com  12/08/98 11:06 -------
What driver are you using?

------- Additional Comments From bubar@albany.net  12/10/98 15:45 -------
I did a little testing this morning and the problem appears to be
ghostscript. I could do all kinds of Text printing but once I sent a
postscript test it balked and I had to senda text job to free it.
Comment 3 Bill Nottingham 1998-12-29 11:08:59 EST
fixed in rhs-printfilters 1.47-3

Note You need to log in before you can comment on or make changes to this bug.