Possible timing problems with rastertosamsungspl

[b1b1]

(Printer=SCX-4825FN via USB, OS=Ubuntu 12.04, driver=4.00.35 not from repo, problem=garbage printing from Chrome, Evince etc).

Another day, another discovery about my "garbage printing" problems: I've been able to fix them by writing output to the printer without delays (caused by ghostscript). Create a shellscript rastertosamsung.sh:

Code: [Select]

#!/bin/sh
`dirname $0`/rastertosamsungspl.orig "$@" >/var/tmp/output.$$
cat /var/tmp/output.$$
rm /var/tmp/output.$$

Then move the existing filter (so it can be run by the new one) and install the new one:

Code: [Select]

sudo mv -n /usr/lib/cups/filter/rastertosamsungspl /usr/lib/cups/filter/rastertosamsungspl.orig
sudo install -m 755 rastertosamsung.sh /usr/lib/cups/filter/rastertosamsungspl

You should be able to revert by reinstalling from the repo: apt-get --reinstall install samsungmfp-driver

Note 1: This seems to work for me but I haven't done much testing.

Note 2: This works as an alternative to my previous "samsungmfp-driver-pdf-fix" (pdftocairo) fix. In fact, it may be that the other fix works simply because ghostscript is able to run faster with the output from pdftocairo. You should probably remove the other fix with apt-get remove samsungmfp-driver-pdf-fix

Note 3: The rastertosamsungspl binary forks and starts ghostscript, then immediately writes the output header. It then waits for output from ghostscript before writing the rest of the output. I suspect the printer may be unhappy about the delay after receiving the header.

Note 4: If anyone has success with this fix, please post and let me know!

Oh, and if you're not happy with the instructions above, just paste the following into a terminal window. It has the same effect:

Code: [Select]

echo -e '#!/bin/sh\n`dirname $0`/rastertosamsungspl.orig "$@" >/var/tmp/output.$$\ncat /var/tmp/output.$$\nrm /var/tmp/output.$$' >rastertosamsung.sh
sudo mv -n /usr/lib/cups/filter/rastertosamsungspl /usr/lib/cups/filter/rastertosamsungspl.orig ; sudo install -m 755 rastertosamsung.sh /usr/lib/cups/filter/rastertosamsungspl


[bchemnet]

I can see where this would work, but can't immediately see a packaging solution that wouldn't run a high risk of breaking something.  I've added this as a possible solution to the website troubleshooting list.

[yurvol]

Wihoo!!!
Worked for me :)
Mint 12 Lisa; USB; printer= 4623FW

All this because ghostscript delays stuff to the printer??  What's up with that?


Thanks dude!

[kenwyn]

Genius! Worked for me too.  Thanks.

[Diego]

I would use mktemp instead of a hardcoded file name. This way two print jobs can be sent at the same time without messing.

Code: [Select]

#!/bin/bash
TMPFILE = `mktemp` || exit 1
`dirname $0`/rastertosamsungspl.orig "$@" > $TMPFILE
cat $TMPFILE
rm $TMPFILE


[Diego]

Sorry, whitespaces in wrong place: now fixed.

Code: [Select]

#!/bin/bash
TMPFILE=`mktemp` || exit 1
`dirname $0`/rastertosamsungspl.orig "$@" > $TMPFILE
cat $TMPFILE
rm $TMPFILE


[bchemnet]

Good addition, thanks for sharing.

[b1b1]

I would use mktemp instead of a hardcoded file name. This way two print jobs can be sent at the same time without messing.

It's not hardcoded. It appends $$ (the shell's PID) to create a unique filename. mktemp may be useful though, if you are concerned about malicious users mounting a timing attack on the filename.

A better solution would be to avoid a temporary file, buffer the output header in memory, then write when the rest of the data starts flowing. Maybe dd could do this, or maybe a little Python script...

[bchemnet]

Even better would be if it just worked without this.  I am starting to assemble new packages based on the 4.00.36 and 4.00.39 drivers; perhaps one of those will address this problem.  With a bit of luck, I'll have those uploaded within a week.

[Diego]

I would use mktemp instead of a hardcoded file name. This way two print jobs can be sent at the same time without messing.

It's not hardcoded. It appends $$ (the shell's PID) to create a unique filename. mktemp may be useful though, if you are concerned about malicious users mounting a timing attack on the filename.

A better solution would be to avoid a temporary file, buffer the output header in memory, then write when the rest of the data starts flowing. Maybe dd could do this, or maybe a little Python script...

Sorry on my mistake. My bash scripting abilities are somewhat rusty. Reading bash man page again is in my to-do list.

[slonnik]

seems like it worked for me too
Thanks

[uspenna]

I have tried both: "samsungmfp-driver-pdf-fix" and the script suggested in this thread (one at a time, course). None has worked.
What I have noticed is that if I print in grayscale - no matter if the original PDF file is colored or in black and white - the printing is good and the pages are fine.
However if I try to print in color mode - no matter if the original PDF file is in black and white or it is colored - the printing gets that strange Text/Graphics printing.
I can reproduce that all the time.
Any suggestions?
I am using Ubuntu 12.04.1 LTS and my printer/multifunctional is a Samsung CXL 3180N and I am using the samsungmfp 4.00.39-1 version.

[bchemnet]

Is this only an issue when printing PDF files?  My printer (CLP-550N) also works perfectly printing anything black & white, but routinely (not always) chokes on color prints unless I switch the driver to the CLP-500 (which is an SPL printer instead of PS).  Over several years I've never found a proper solution.  If you only have the problem with color PDF prints, then pursuing the issue as in this thread might make sense.  Otherwise (or in addition), you might want to try different drivers and/or print protocols to see if it helps.  (And possibly program printing from?)

[uspenna]

Good question!
I just have done the test with Firefox, evince and Chrome right now.
All color printing get garbage printing. But if I choose grayscale, the same pages I have tried printing in color, get printed correctly.
I can reproduce all the time.
I have no idea when this behaviour started because I do not print in color often (in fact, rarely) but I can assure I already have printed in color in the past with no problems at all.
Thanks for your attention.
I can do more tests or be a beta if you wish.
before I forget: cups version 1.5.3

[bchemnet]

Have you tried the older driver version packages (e.g., 4.00.35 or 3.00.65)?  This series of printers seems to be the cause of at least half the recent posts about problems, so I suspect it may be quite finicky about which version of the driver is used.  That might also account for the "it worked before" issue.