CLP510-N Printing unwanted stuff outside printing area
Brought to you by:
ap2c
Menu
▾
▴
#69 CLP510-N Printing unwanted stuff outside printing area
The current version of splix does not work well with Samsung CLP-510N (former does).
If printing with Splix 2.0 the printer prints outside the printing area.
This starts only on the second page, first page is printed ok.
System:
Kubuntu 10.10 AMD 64
Splix V2.0 (Tested with ALL ppds for CLP-510)
Printed with: Kde okular (other apps also don't work)
Language Setting/Keyboard: German
Deleted Version 2.0, downloaded, compiled and tested Version 1 -> works fine.
Appears to be K/Ubuntu issue as 10.04.1 also has Splix 2.0.0 - version in 10.04.1 reports as 2.0.0-2ubuntu3 and works correctly, version in 10.10 reports 2.0.0+20100802-0ubuntu4.
The problem is most probably caused by this patch
http://sourceforge.net/tracker/?func=detail&aid=2880411&group_id=175815&atid=874748
which got applied to the SVN repository (and also the Ubuntu package) because of another bug.
This is also reported to Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/splix/+bug/714259
Scans of printouts of the newest SVN snapshot are attached.
Hi,
As for the suspected patch Till mentioned, probably is unrelated as this touches 2 files for encoding algorithm 0xd, so it is not what this model probably uses.
Long ago, Aurelien introduced a late feature called "Manual duplex", this feature is supposed to semi-automate duplex printing, maybe this does not work on all models, perhaps it is worth investigating,
Regards.
Another possibility is, as of Revision 267 - 'Applied PostScript header patch.' in the file pstoqpdl.cpp six month ago, this could be if CLP510-N uses it and was working before the patch was applied as reported by users.
Regards
lhamada, I have checked revision 267. It only affects you if you are using color profiles for your printer. Are you using them?
The reporter of the Ubuntu bug does not use color profiles, so rev. 267 is not the culprit.
lhamada, I have seen that you have contributed code to SpliX. Perhaps you could find out what the problem is?
Important to say is that the SpliX 2.0.0 (SVN rev. 259) still worked and at least from SVN rev. 283 on it stopped working.
Christian, can you try the following:
Edit the PPD file of your print queue (/etc/cups/ppd/<name of print queue>.ppd) replacing the line
*cupsFilter: "application/vnd.cups-postscript 0 pstoqpdl"
by
*cupsFilter: "application/vnd.cups-raster 0 rastertoqpdl"
Then restart CUPS, either with (one of them should work)
sudo restart cups
or with
sudo /etc/init.d/cups restart
After that clear all dangling jobs with
cancel -a
and try to print again. Does it work correctly now?
A user on the Ubuntu bug report tells that the workaround described in my previous comment solves the problem. The workaround removes the use of the pstoqpdl wrapper. The wrapper serves for nothing else than injecting PostScript code for color management, so not using it should not break anything for users who do not use color management. This means also that the bug is in the wrapper, so we must look into what has changed in it in the mentioned revisions.
Note that (K)Ubuntu 10.04 has the released 2.0.0 and (K)Ubuntu 10.10 the SVN snapshot (the version number has the snapshot date added). To find out ehther Ubuntu or whether the changes on the SpliX SVN cause the problem, you should test Ubuntu 10.04 with the SVN snapshot of SpliX (by building from upstream SVN source or by installing and if needed rebuilding the 10.10 package on (K)Ubuntu 10.04 and/or trying the released 2.0.0 on (K)Ubuntu 10.10 (by using the SpliX package from OpenPrinting). Can you please do so and report your experience here? Thanks.
I proposed a modification in comment #25 on launchpad https://bugs.launchpad.net/ubuntu/+source/splix/+bug/714259
Some CMS files to tinker with are available at http://splix.ap2c.org/samsung_cms.tar.bz2 according to INSTALL file.
If it solves the issue, I'll attach a patch here later.
I have committed the proposed modification from lhamada to the SVN repository now (rev. 294). Even if it does not solve this bug, it makes sure that no double free can happen when handling the color correction files.
Everyone, please test SpliX with lhamada's patch applied. Please tell whether it fixes this bug or not. Thanks.
lhamada, thank you very much for the patch.
(Some update)
While inspecting image from printout file while developing the newly added printers (clp315), a very similar phenomenon to this issue was perceived. The first page is ok but from second and beyond either is half garbled or with unwanted items around borders on the page.
This can be reproduced even without using SpliX on Ubuntu 10.10 and by just dumping an cups raster intermediate data and inspecting it.
Using Michael Sweets' rasterview tool and associated files one can do the following.
The problem with rasterview as is, is that the next page button on the left bottom of its view window (looks like | >|) is disabled, so you cannot inspect beyond the first page. Believing the first page is visually ok, one could falsely imply that the rest of the other pages are too.
You need to build rasterview from source and comment out the line that is disabling the next buttom on file RasterView.cxx before compiling, line 341:
//next_button_->deactivate();
To capture a cups raster file, one could:
- Get a postscript file and rename to testprint.ps and run the associated maketestfiles.sh script.
After generating color raster data with 600dpi resolution for example (default 100dpi does seem not to be affected) , open with rasterview, from the second page you probably can see artifacts.
rasterview's maketestfiles runs pstops->pstoraster filters, pstoraster is the same one that pstoqpdl internaly relies. (pstoraster->rastertoqpdl).
The pstoraster filter relies on gs cups device but I haven't nailed further down on with parameter (or lack of it) makes this behavior occur.
So after finding about a newer gstoraster alternate filter, that elaborate more on its internal preprocessing, it too relies on gs cups device, but the output using gstoraster is correct.
The current SpliX revision will use the gstoraster filter if present or you can install it manually to the /usr/lib/cups/filter/ directory.
Thanks