Arch Linux

This was an upstream decision: http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/revision/7480

We ship plain new upstream behavior. All ghostscript related filter stuff is there. Have you recreated the printer queue?
A symlink should not be required.

I'm not sure if the old pstopdf is hardcoded in some configuration file. You can grep for it.

The forum thread says a closed source Xerox driver is broken now. Is that the only broken device?

> Have you recreated the printer queue?

Hmm - ok, no. First, if I *needed* to recreate the printer queue, I would say that there should have been a big fat note during the install of cups-filters saying so.

Yes, now I have recreated the printer queue for a laserjet 6mp. There are no more failures with the discontinued pstopdf, but now, instead, there are print failures with a missing "ijsgutenprint"! The result is that the drivers

HP LaserJet 6MP Foomatic/gutenprint-ijs-simplified.5.2
HP LaserJet 6MP Foomatic/gutenprint-ijs.5.2

will fail, where the log includes, for instance,

cupsd[13385]: GPL Ghostscript GIT PRERELEASE 9.20: Can\'t start ijs server \"ijsgutenprint.5.2\"
cupsd[13385]: renderer exited with status 1
cupsd[13385]: Possible error on renderer command line or PostScript error. Check options.STATE: +connecting-to-device
cupsd[13385]: Kid3 exit status: 3
cupsd[13385]: PID 12258 (/usr/lib/cups/filter/foomatic-rip) stopped with status 9.
cupsd[13385]: Hint: Try setting the LogLevel to "debug" to find out more.
cupsd[13385]: STATE: -connecting-to-device
cupsd[13385]: STATE: -media-empty-error,media-jam-error,hplip.plugin-error,cover-open-error,toner-empty-error,other
cupsd[13385]: Expiring subscriptions...
cupsd[13385]: ready to print
cupsd[13385]: Expiring subscriptions...
cupsd[13385]: PID 12259 (/usr/lib/cups/backend/hp) exited with no errors.
cupsd[13385]: Job stopped due to filter errors; please consult the error_log file for details.

And yet, the printer prints a page containing only the single line:

**** Unable to open the initial device, quitting.

which is kind of annoying. Still, there are several other drivers available which work just fine. Nevertheless...

It seems that ijsgutenprint is no longer compiled in gutenprint. "Why" is not clear. In the gutenprint source, README.package says specifically:

* We recommend packaging the IJS driver
(/usr/bin/ijsgutenprint.5.2) and its man page
(/usr/man/man1/ijsgutenprint.1.gz) together with the Foomatic
data.

But then, it does not say how to do this. And then, there is this:

https://sourceforge.net/p/gimp-print/mailman/message/34782748/

"... 2016-01-20 ...
I'm looking to get gutenprint to cross compile, and I'm hitting a few
obstacles:
(1) The build system uses the 'ijs-config' tool to determine the
compiler and linker flags. This yields include paths for the host
system, not the build system.
...
I just applied that patch -- since, in order to resolve the discrepancy,
upstream ghostscript just removed ijs-config altogether. Might as well
do things the proper way. :)
..."

Andy, maybe you can make sense of all that. The file "gutenprint-5.2.11/src/ghost/ijsgutenprint.c" is still there, but it does not compile. If ijsgutenprint is being discontinued, then the associated disfunctional drivers should also be removed.

When recreating the printer queue fixes the pstopdf not found issue this is not a bug in cups-filters.

You are running into a more complex problem with your desired driver. You don't want that ijs driven driver.
We have lost gutenprint-ijs capabilites with ghostscript 9.19 release.

http://www.ghostscript.com/doc/9.19/History9.htm - grep there for ijs
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0c176a91d53c85cdacd7917c76d6f659125ac3f6

Gutenprint will drop ijs pretty soon too it seems:
https://sourceforge.net/p/gimp-print/mailman/gimp-print-devel/thread/201601300111.u0U1BnMC011686%40dsl092-065-009.bos1.dsl.speakeasy.net/#msg34806962

There's some libijs from openprinting project. But I'm not sure what it's all about and how to use it. I see only
Debian and BLFS packaging this one.

You should change your driver to something different:

https://www.openprinting.org/printer/HP/HP-LaserJet_6MP - you should probably go with hplip driver or some generic PostScript driver.

I should drop foomatic-db-gutenprint xml driver database. It seems useless since last ghostscript release.

It seems possible to build libijs and make ghostscript and gutenprint depend on this lib. That way gutenprint-ijs drivers should keep working for now.
I'll have a look a this.

Anyway you should move to a more recommended driver.

Oops - don't click the "refresh" button ...

Please test new packages ghostscript/ijs/gutenprint in testing. The gutenprint-ijs driver should work now again.

Anyway you should switch later using the upstream recommended driver...

> You should change your driver to something different:
> Anyway you should move to a more recommended driver.
> Anyway you should switch later using the upstream recommended driver...

Andy, I was only testing the foomatic/gutenprint-ijs.5.2 drivers to see if there were problems. I actually prefer the hpijs pcl3 driver. Oddly, the recommended Postscript driver produces the best quality, but the printer is very slow with this driver, and "/usr/lib/cups/backend/hp" segfaults after installing more memory in the printer,
kernel: hp[16154]: segfault at ffffffff ip 00007fef7dbae0ac sp 00007ffd3d990b20 error 4 in libc-2.23.so[7fef7db65000+197000]
But that segfault is on the hplip people.

> Please test new packages ghostscript/ijs/gutenprint in testing.

Uhm - you forgot to recompile gutenprint for testing. But recompiling here, it generates ijsgutenprint.5.2 and printing works. The driver seems to give the same results as the CUPS+Gutenprint driver, so it's not providing anything special.

Otherwise, it all works now. You still might want to add some note about when needing to recreated the printer queue, though.

There's gutenprint 5.2.11-4 in testing. Maybe your mirror hadn't had it at that time. I will move the packages later to extra.

Printer queues break every now and then in a rolling release distribution. You can't avoid it and there's no certain criteria
when to recommend it. Feel free to add a note to our wiki pages.

Closing this issue here.

For your segfault with hplip driver make sure you memory isn't broken by hardware. No idea if there's some memtest for printers.
If only the memory amount breaks it please get in touch with hplip devs -> upstream bug.