SULDR Forums Supported Printers Printing Questions Scanning Questions General Questions Samsung Installer

Possible timing problems with rastertosamsungspl

Started by b1b1, June 10, 2012, 05:43:44

Previous topic - Next topic

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:


#!/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:


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:


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


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.


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



Diego

Sorry, whitespaces in wrong place: now fixed.



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

bchemnet


b1b1

Quote from: Diego on September 03, 2012, 07:54:13
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

Quote from: b1b1 on September 23, 2012, 10:49:04
Quote from: Diego on September 03, 2012, 07:54:13
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


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

#13
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.

Repository Information Legal Contact Alternative Drivers