Chromium-generated PDF does not print on Samsung SCX-3200 on USB via Samsung's driver

Thank you for reporting this bug.

CUPS can't find the pstoraster driver on your system, which doesn't exist anymore (apparently it's called gstoraster now). However, your /etc/cups/mime.convs still points to pstoraster. This file shouldn't exist anymore, as CUPS's mime conversion files are now in /usr/share/cups/mime.

Long story short, deleting /etc/cups/mime.convs might already solve your problem. The file is not part of the system anymore and won't be reinstalled.

Please let me know if that fixes your bug.

If your /etc/cups/mime.convs contains manual changes which you do not want to sacrifice, please remove the line(s) with "pstoraster" or replace all occurrences of "pstoraster" by "gstoraster", after that restart CUPS ("sudo restart cups" in a terminal window). If you never edited /etc/cups/mime.convs and do not have any proprietary printer drivers which could have modified this file, remove the file and then restart CUPS. Then your problem should disappear.

No of suggestions helped.
I'm using Samsung Universal Driver from bchemnet.com.
I found that Acrobat Reader can print some of pdfs, but when I switched to "Print as image" it started to print usual garbage.

If removing /etc/cups/mime.convs did not help, please attach CUPS' error_log again (or re-run the print troubleshooter).

Last printing, seen in error log, produced garbage. It was done from AcrobatReader with Print As Image option. Printed pdf file was attached in bug report. Part of earlier printouts succeeded.

Can you also attach the PPD file for your printer (from /etc/cups/ppd/)? Thanks.

I found workaround.
I've noticed that printing performed from remote machines (printer shared by samba) always succeeded, so I added new printer which connects to http://localhost:631/... and so far all is working fine.

The PPD file you attached in comment #8 states that rastertosamsungpl accepts PostScript in line 29.

Changing that line to accept raster might solve your problem:

  *cupsFilter: "application/vnd.cups-raster 0 rastertosamsungspl"

Till, do you know where a bug for that PPD can be filed?

Did not help and caused error, when printing stared, so error is somewhere else.
With this change or without, my workaround is still working.

Job 1515 was created by "fake" printer and send to backend http. Job 1516 was received over http and sent to usb backend (as far I understand). If job 1515 was send directly to usb it would produces garbage. Going through http fixes the problem.
In my opinion http causes only, that job is first created and later sent in single not interrupted, complete stream to usb backend. In direct case job may be sent in several chunks (and not single single step), because filter "stack" pstops/rastertospl does not produce steady stream. Or pstops/rastertospl stack finishes job (closes output, sends EOF or so) and when it is received by usb backend it interrupts uploading job to the printer (even there are still some data to upload).
It is only my guessing, so does it make any sense?

Slawek Pudlis, what you can do also is running the command

cupsctl FileDevice=yes

and then create print queues with several different drivers for your printer but with the URIs file:/tmp/splix, file:/tmp/SamsungSPL, ... and print one and the same job to each of the queues. Then print each of the resulting files unfiltered to your printer on USB, for example with the command

lpr -P printer -o raw file

with printer being your print queue of your printer directly on USB and file a file from /tmp. This way you can see which drivers produce correct data for your printer to print with all timing issues eliminated. If you get a driver working this way but not directly the problem are only timing issues.

Thank you Till.
Hopefully problem is only timing issue.
I've created printer which sends output to file. I used original PPD, without Lars suggestion.
I've printed my problematic job to the file and produced file I sent directly to usb. Result was correct.
I'm happy with my workaround, so you may close Bug.

Slawek, thank you very much.

To solve the timing problem, can you

1. Print to a file with the free software drivers (SpliX, Foomatic/foo2qpdl, Foomatic/pxlcolor, ...) and then send these resulting files unfiltered the USB printer. If we have a free software driver which prints for you with the timing issue worked around, we can perhaps modify the driver, for example by writing the output into a temporary file and when it completes send all to the printer at once.

2. Run the command

sudo modprobe usblp

and then create a print queue with a driver which works with your printer and with the URI file:/dev/usb/lp0 Does this queue print reliably? If so, the problem is in the kernel or perhaps the USB CUPS backend. Run the command

sudo rmmod usblp

after this test.

Thank you Till again,

I do not follow. You suspect that problem is in the kernel or in USB CUPS backend, don't you? So why do you suggest to fix problem in SpliX, Foomatic/foo2qpdl, Foomatic/pxlcolor, ...? Isn't easier to fix single place - origin of the problem?
I understand that kernel is out of your scope, but if it is the origin ...

I did the second test, but still with my favorable driver from Samsung.
cat /tmp/SamsungSPL > /dev/usb/lp0
job is printed correctly.

Printing directly to file:/dev/usb/lp0, produce usual garbage.

Thank you for the tests. They show that it does not matter whether you use the old method of the "usblp" kernel module or the new method of using libusb to print. The timing issue occurs with both methods.

This still does not say whether the culprit is the kernel or the filter/driver chain. The USB CUPS backend is less probable as the problem is also triggered by a print queue pointing to file:/dev/usb/lp0. This queue does not use the USB CUPS backend but the filter/driver chain and the kernel are still used.

If the printer worked correctly under Ubuntu 11.04 or 10.10, the problem is most probably a kernel problem as the filter chains of 11.04 and 10.10 were significantly slower than of 11.10.

I've given chance for Splix. I used PPD for SCX-4600. It looks to be quite similar printer. It is working without any workarounds.

Thank you again

Slawek, does this mean that you can now print directly to USB without any timing problems? Are the colors (at least approximately) correct? Are you using SpliX from Ubuntu or from OpenPrinting?

Yes, I can print problematic pdf directly to usb without any problems. The same with printing from Chromium. I'm starting to use this as my default printer and will see if there are any side effects.

Colors are ok, beside the fact there are only gray levels, but it acceptable misfeature of b/w printer.

I'm using Splix from Ubuntu.

Great, this means that we can fix this bug for Ubuntu by simply adding a PPD for your printer model to the SpliX package. Thank you very much for all the tests.

Added Samsung SCX-3200 in upstream SVN repository of SpliX.

Attached is the new PPD file. Please try it out. If you place it in /usr/share/ppd/custom/ and remove all queues for your printer and after that unplug the printer from the USB and plug it in again, you can test the auto setup for your printer. Please tell whether this works. After the test remove the PPD file from /usr/share/ppd/custom/ so that when new SpliX packages with the PPD file included appear it is assured that only an up-to-date PPD file is on your system.

Auto setup is not working. It looks like ppds are looked for in /usr/share/cups/model and not /usr/share/ppd/. I've added sym link to custom and then it starts to recognize and installs automatically.

Additionally I had to remove ppd file provided by Samsung driver, because it takes precedence over ppd file in custom directory. In my opinion, if more then one ppd file matches, user should have chance to make decision.

Slawek, thank you very much. If we have packaged SpliX with the new PPD added, users without Samsung's driver installed will automatically get this PPD.

This bug was fixed in the package splix - 2.0.0+20111206-0ubuntu1

---------------
splix (2.0.0+20111206-0ubuntu1) precise; urgency=low

  * New upstream release
     - SVN snapshot from Dec 6, 2011
     - Added Samsung SCX-3200 (LP: #898385).
  * debian/rules: Run "make clean" also with "DISABLE_JBIG=1", otherwise
    "make clean" falls into an infinite loop without the JBIG library
    being present and the package FTBFS.
 -- Till Kamppeter <email address hidden> Tue, 06 Dec 2011 23:37:46 +0100

It still happens. It really rare with Splix. Using Splix does not solve the problem, but makes it less frequent.

I did small test. I've created my own backend (bash script), which redirects stdin to some file, and when it is finished sends file to /dev/usb/lp0. It is working well even with Samsung driver. When my script redirects directly to stdout, it produces problem.

So: the same content, but sent in single not interrupted stream makes difference. It may suggest that it is some timing issue, which should be addressed in usbbackend and not in Splix or Samsung driver.

I think that interrupt in input stream is interpreted by Samsung printer as end of job. If uploaded data is not complete, printer tries to print as plain text, and does not wait for rest of job.

I'd like to try cups' filter ability in order to implement buffering, but it is out of my knowledge. If you may suggest something I'm open to try your suggestions.

Please try the CUPS package of my PPA

https://launchpad.net/~till-kamppeter/+archive/ppa

It contains a USB backend which uses the newer libusb 1.0.x. Perhaps this works.

Otherwise, this problem could be a kernel problem, bug 917148.