foomatic-rip-hplip lets Ghostscript stdout messages appear on the printer

Bug #624024 reported by Johannes Meixner
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
HPLIP
Confirmed
Undecided
Unassigned
hplip (Arch Linux)
Confirmed
Undecided
Unassigned

Bug Description

We (i.e. openSUSE/Novell) got this bug report:

https://bugzilla.novell.com/show_bug.cgi?id=633468

In short:

The way how foomatic-rip-hplip calls gs lets whatever
Ghostscript stdout messages appear on the printer.

Details:

I can reproduce it with HPLIP 3.10.2
on a openSUSE 11.3 x86_64 system.

We build HPLIP with those configure settings:

./configure --prefix=/usr \
            --libdir=%_libdir \
            --disable-qt3 \
            --enable-qt4 \
            --disable-policykit \
            --enable-doc-build \
            --enable-network-build \
            --enable-pp-build \
            --enable-scan-build \
            --enable-gui-build \
            --enable-fax-build \
            --enable-dbus-build \
            --enable-hpcups-install \
            --disable-cups-drv-install \
            --enable-cups-ppd-install \
            --enable-hpijs-install \
            --disable-foomatic-drv-install \
            --enable-foomatic-ppd-install \
            --enable-foomatic-rip-hplip-install \
            --with-hpppddir=%{_datadir}/cups/model/manufacturer-PPDs/%{name} \
            --with-cupsbackenddir=/usr/lib/cups/backend \
            --with-cupsfilterdir=/usr/lib/cups/filter \
            --with-drvdir=/usr/lib/cups/driver \
            --with-mimedir=%{_sysconfdir}/cups \
            --with-docdir=%{_defaultdocdir}/%{name}

The PPDs which use the hpijs driver contain lines like

*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip-hplip"
*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip-hplip"

foomatic-rip-hplip calls gs in a traditional way

 gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE \
    -sDEVICE=... -sOutputFile=- -

This way, unexpected output of Ghostscript on stdout
like whatever Ghostscript error and warning messages
are sent like the usual payload to the next filtering stage
so that in the end it appears on the printer.

Unfortunately there is no simple Ghostscript commmand line switch
which completely disables such unwanted output on stdout.
Only -q and -dQUIET are not sufficient in any case
but meanwhile '-sstdout=%stderr' might be sufficient.

Therefore e.g. foomatic-rip calls gs nowadays this way

  gs -sstdout=%stderr -dBATCH -dPARANOIDSAFER -dQUIET \
    -dNOPAUSE -sDEVICE=... -sOutputFile=%stdout -_

This way, unexpected output of Ghostscript on stdout
like whatever Ghostscript error and warning messages
are redirected to stderr whereto they acutally belong.

Since 2006-08-27 Till Kamppeter used the -sstdout=%stderr
in foomatic-rip - his foomatic-rip ChangeLog entry is:
--------------------------------------------------
foomatic-gswrapper.in: Support for built-in redirection of
standard output of PostScript programs ("-sstdout=%stderr") in
newer GhostScript versions. More reliable then using /dev/fd/3
(not always available, difficult to check presence) or '|cat >3'
(not seekable and some GhostScript output devices require
seekability of the output file),
--------------------------------------------------

I suggest to enhance foomatic-rip-hplip accordingly
because I think Ghostscript versions which are available
since 2006 are meanwhile (hopefully) used
on all Linux distributions for which you provide HPLIP.

By the way:

There have been "rumors" that foomatic-rip-hplip is no longer
needed at all by HPLIP and that it can be replaced by foomatic-rip
but if this is really true, why does HPLIP still provide its own
foomatic-rip-hplip?

If I could get a authoritative statement from HPLIP that
foomatic-rip-hplip is not and will not be needed by HPLIP
I would like to get rid of it in the next version of openSUSE.

Please note that I will still provide readymade static PPD files
because I perfer to make them during build time of the package
(which is what I can check whether or not it works)
instead of generating PPDs during run time on each individual
end-user's particular (posibly somewhat broken) system
because I like to avoid possible issues with PPD generation
which depend on each individual end-user's system.

Revision history for this message
Johannes Meixner (jsmeix) wrote :

Correction:

It seems the parameters of the "gs" call
are not set up by foomatic-rip-hplip but
stored in the FoomaticRIPCommandLine
value in each PPD, see in particular

https://bugzilla.novell.com/show_bug.cgi?id=633468#c18

how this might be changed to fix the issue.

Revision history for this message
compgamer89 (compgamer89) wrote :

Verified still present in Arch Linux HPLIP 3.11.7, HP Photosmart C4400 series PPD (along with many others).

Fix in above comment verified to work in Arch Linux.

Manually verified that HPLIP 3.11.10 still lacks the relevant ghostscript flags (-sstdout=%stderr, -sOutputFile=%stdout).

Revision history for this message
compgamer89 (compgamer89) wrote :

For Arch Linux and HP Photosmart C4400 series, relevant use case for reproducing bug: Print through Samba to CUPS printer, using a PostScript driver on Windows-side (e.g. cupsaddsmb drivers).

Behavior: Printing produces an extra sheet before the actual print job, containing comment output from ghostscript.

Root Cause: Ghostscript mixes extra output lines with sOutputFile=-, setting sstdout=%stderr prevents these lines from being passed along. See https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/314439.

Changed in hplip:
status: New → Confirmed
Changed in hplip (Arch Linux):
status: New → Confirmed
Revision history for this message
compgamer89 (compgamer89) wrote :

Seems hpcups does not run into this problem; possible wontfix if hpijs is considered deprecated?

see https://answers.launchpad.net/hplip/+question/184420, answer @goutamkk

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.