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

Bug #898385 reported by SPud
This bug affects 2 people
Affects Status Importance Assigned to Milestone
splix (Ubuntu)
Fix Released

Bug Description

Pdf created by Chromium is not printed correctly by SCX-3200. Instead of content, there are printed pages with single garbage line. Pdf file (taken from /var/spool/cups) is displayed correctly. Printing this pdf file from Acrobat Reader does not change situation, while Acrobat Reader prints other pdf without such problem.
It occurs almost always when I try to print web page from Chromium.
It occurs very rarely when printed from other applications (LibreOffice, Acrobat Reader, etc).
It does not occur before upgrade to 11.10.
It looks similar to or, but before providing fix for that bugs, it was complete disaster - only first print succeeded. Now only part of printings are corrupted (from Chromium almost all, from other sources it is rare).

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cups 1.5.0-8ubuntu5
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
Uname: Linux 3.0.0-14-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Wed Nov 30 22:17:49 2011
EcryptfsInUse: Yes
Lpstat: device for Samsung_SCX-3200_Series: usb://Samsung/SCX-3200%20Series?serial=Z509BFBZC00254J&interface=1
MachineType: System manufacturer System Product Name
Papersize: a4
PpdFiles: Samsung_SCX-3200_Series: Samsung SCX-3200 Series
 PATH=(custom, no user)
ProcKernelCmdLine: root=UUID=080944be-80e2-465a-b251-c22b7fb60f84 ro splash quiet
SourcePackage: cups
UpgradeStatus: Upgraded to oneiric on 2011-10-16 (45 days ago) 02/02/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0802
dmi.board.asset.tag: To Be Filled By O.E.M. M3N18L T-M3N8200
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev x.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0802:bd02/02/2009:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM3N18LT-M3N8200:rvrRevx.xx:cvnChassisManufacture:ct3:cvrChassisVersion: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
mtime.conffile..etc.cups.cupsd.conf: 2011-11-30T19:06:04
mtime.conffile..etc.cups.mime.convs: 2010-09-25T17:31:27

Revision history for this message
SPud (pudlis) wrote :
Revision history for this message
Lars Karlitski (larsu) wrote :

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.

Changed in cups (Ubuntu):
status: New → Incomplete
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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.

Revision history for this message
SPud (pudlis) wrote :

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

Revision history for this message
Lars Karlitski (larsu) wrote :

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

Revision history for this message
SPud (pudlis) wrote :

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.

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

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

Revision history for this message
SPud (pudlis) wrote :
Revision history for this message
SPud (pudlis) wrote :

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.

Revision history for this message
Lars Karlitski (larsu) wrote :

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?

Revision history for this message
SPud (pudlis) wrote :

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

Revision history for this message
SPud (pudlis) wrote :

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?

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

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.

Revision history for this message
SPud (pudlis) wrote :

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.

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

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.

Revision history for this message
SPud (pudlis) wrote :

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.

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

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.

Revision history for this message
SPud (pudlis) wrote :

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

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

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?

Revision history for this message
SPud (pudlis) wrote :

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.

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

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.

Changed in cups (Ubuntu):
status: Incomplete → Triaged
affects: cups (Ubuntu) → splix (Ubuntu)
Changed in splix (Ubuntu):
importance: Undecided → Medium
summary: - Chromium is not able to print on Samsung SCX-3200
+ Chromium-generated PDF does not print on Samsung SCX-3200 on USB via
+ Samsung's driver
Changed in splix (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

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

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

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.

Revision history for this message
SPud (pudlis) wrote :

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.

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

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in splix (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
SPud (pudlis) wrote :

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.

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

Please try the CUPS package of my 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.

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.