HPLIP filtering rules pstotiff.convs can mess up normal CUPS filtering

Bug #1391963 reported by Johannes Meixner
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
New
Undecided
Unassigned
Fedora
Fix Released
Undecided

Bug Description

HPLIP's pstotiff.convs contain
---------------------------------------------------
application/postscript image/tiff 80 pstotiff
application/pdf image/tiff 80 pstotiff
application/vnd.cups-pdf image/tiff 80 pstotiff
application/vnd.cups-postscript image/tiff 80 pstotiff
---------------------------------------------------

Wihout HPLIP's filtering rules the normal CUPS
upstream filtering for PostScript is done via
/usr/lib/cups/filter/pstopdf
and
/usr/lib/cups/filter/pdftopdf

Wih HPLIP's filtering rules filtering for PostScript
is subverted into something like
/usr/lib/cups/filter/pstotiff
and
/usr/lib/cups/filter/imagetopdf

The reason why HPLIP's entries in its pstotiff.convs
mess up the normal CUPS upstream filtering is:

When HPLIP adds CUPS filtering rules via a *.convs file
for standard MIME types like application/postscript and
application/vnd.cups-postscript then those rules become part
of the standard CUPS filtering which means those rules
affect all print jobs with that standard MIME types.

In other words:
What CUPS filtering happens depends on the MIME types so that
for same MIME types same CUPS filtering happens and
when HPLIP needs different CUPS filtering rules
then HPLIP must use different MIME types.

Currently that bad filtering rules in the HPLIP software
get deactivated/hidden in a fragile way by other ("cheaper")
filtering rules from the cups-filters package that take
precedence over HP's problematic filtering rules.

But that is no real solution because it means that without
the filtering rules from the cups-filters package the user
gets HPLIP's non-working filtering via HPLIP's pstotiff
for all his PostScript and PDF print jobs.

I think a real solution should be that HPLIP uses special
HPLIP-specific MIME types for its HPLIP-specific filtering.

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

CUPS 1.6 will have major incompatible changes:

"Transition all non-Mac filters to OpenPrinting"
http://www.cups.org/str.php?L3930
"Deprecate and stub out image file support"
http://www.cups.org/str.php?L3931

"Drop serial and parallel backends"
http://www.cups.org/str.php?L3935

"Drop support for CUPS Browsing and Polling"
http://www.cups.org/str.php?L3922
"CUPS browsing is deprecated and scheduled for removal ... after 1.5.x"
http://www.cups.org/str.php?L3889
"Bonjour is the replacement"
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22Why+is+CUPS+browsing+deprecated%22

"Deprecate PPD functions"
http://www.cups.org/str.php?L3926
"Deprecate the PPD compiler"
http://www.cups.org/str.php?L3927
"Support for PPDs is not going away in CUPS 1.6"
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22CUPS+1.6+and+PPD%22

In general for changes in the upcomming CUPS version 1.6 see
http://www.cups.org/roadmap.php?VERSION=1.6

Revision history for this message
In , Tim (tim-redhat-bugs) wrote :

Description of problem:
When trying to convert application/postscript to application/vnd.cups-pdf, the pstotiff filter (from HPLIP for faxing support) gets used:

application/postscript
  -> application/pdf via pstopdf (100)
  -> application/vnd.cups-pdf via pdftopdf (66)
  = 166

application/postscript
  -> image/tiff via pstotiff (80)
  -> application/vnd.cups-pdf via imagetopdf (33)
  = 113

So the pstotiff path wins.

CUPS Raster drivers such as gutenprint seem to be unaffected:

application/postscript
  -> application/vnd.cups-postscript via pstops (66)
  -> application/vnd.cups-raster via gstoraster (100)
  = 166

application/postscript
  -> image/tiff via pstotiff (80)
  -> application/vnd.cups-raster via imagetoraster (100)
  = 180

Version-Release number of selected component (if applicable):
cups-filters-1.0.35-3.fc19.x86_64
hplip-3.13.7-1.fc19.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Set up a queue using a Foomatic driver
2.Submit a PostScript job
3.Examine the filters used (e.g. cupsctl --debug-logging, then view error_log)

Actual results:
pstotiff is used

Expected results:
pstotiff not used

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

Package ghostscript-9.07-12.fc19, cups-filters-1.0.36-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ghostscript-9.07-12.fc19 cups-filters-1.0.36-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-15111/ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19
then log in and leave karma (feedback).

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ghostscript-9.07-12.fc19, cups-filters-1.0.36-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ghostscript-9.10-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ghostscript-9.10-4.fc20

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ghostscript-9.10-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

The problem with the pstotiff->imagetopdf filter chain is known and I have fixed the problem in cups-filters 1.0.37. Please update to the newest cups-filters (today I released 1.0.39).

affects: cups (openSUSE) → opensuse
Changed in opensuse:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
Johannes Meixner (jsmeix) wrote :

Good grief!

Launchpad's inter-bugtracker facilities had automatically
imported tons of comments from the openSUSE bug
http://bugzilla.opensuse.org/show_bug.cgi?id=735404
that are mostly totally unreladed to this issue here.

I remove the link to that openSUSE bug here.

no longer affects: opensuse
Revision history for this message
Johannes Meixner (jsmeix) wrote :

Is it somehow possible to remove all that mostly useless
imported comments from the openSUSE bug here or
perhaps make them at least somehow invisible here?

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

I clicked [Hide] for all the useless imported comments
from the openSUSE bug here except the two comments
in the openSUSE bug that actually match this issue here.

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

O.k. [Hide] seems to work to make them invisible here.

Changed in fedora:
importance: Unknown → Undecided
status: Unknown → Fix Released
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.