Cups > 1.6 without Ghostscript,via. poppler on Slackware 14

Andrew Robinson andrew3 at r3dsolutions.com
Fri Oct 26 12:11:01 PDT 2012


> Andrew Robinson <andrew3 at r3dsolutions.com> writes:

>
> > Regarding filtering in general (and not the alternate set); are you
> > aware of any test files that one could attempt to print (for example a
> > raster file) so that only the rastertoepson filter and the cups 1.6.1
> > backend would be involved (to see if the ppd file & cups 1.6.1 is good
> > exclusive of the other package?)
> >
> > Or is there a debugging switch and a way to capture the raster file
> > generated so I can see what it attempted to send to the epson raster
> > program/backend ?
> >
> > (I'm trying to find easy ways to isolate the problem(s).)
>
> You could activate output to file, for debugging, and then, e.g.,
> /tmp/foo would hold the raster image that would have gone to your
> printer.
>
> In /etc/cups/cupsd.conf you need to add:
>
> FileDevice Yes
>
> And then you need, AFAIK, create the file printer with lpadmin. Then,
> in CUPS GUI you can set its driver to be the R200. For example, after
> that, my printers.conf ends up with the following entry, using a Canon
> printer driver here:
>
> <Printer foofile>
> UUID urn:uuid:fedae68d-3fa7-3aa3-73c9-0eba1ee02721
> Info foofile
> MakeModel Canon BJC-5500 - CUPS+Gutenprint-CVS v5.2.9
> DeviceURI file:/tmp/foo
> State Idle
> StateTime 1344670554
> Type 8450060
> Accepting Yes
> Shared No
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy retry-job
> </Printer>
>
> --
> Gernot Hassenpflug
>

Hi Gernot!

Your suggestion is good,useful ... and still bad. :)
It's not the cups raster file which was produced when I tried your suggestion -- but rather the actual printer encoding.  I have a work-around, but I thought I'd share what happened... (If your eyes glaze over, I have a simple question at the end of the post... ;) )

Here's what I did (and note, I installed cups in /usr/ so on your system all directories ought to be the same, minus the leading /usr/)...

do in shell:
/etc/rc.d/rc.cups stop

edit using vim:
/usr/etc/cups/cupsd.conf
add line: FileDevice Yes

do in shell:
lpadmin -p printToFile -v /tmp/printToFile
/etc/rc.d/rc.cups restart

Web-browse to: 127.0.0.1:631/admin
Add a printer: call it printToFile having an epson photo driver.
(any epson printer driver would work to replicate my tests, even if you don't have an epson printer...!)

do in shell:
/etc/rc.d/rc.cups stop

# There is a bug in the way the add printer chooses the directory in cups 1.6.1
# so here's how I worked around it

edit: /usr/etc/cups/printers.conf
change DeviceUri line to --> DeviceUri file://tmp/printToFile

edit: /usr/etc/cups/ppd/printToFile.ppd
Change the word rastertoepson into rastertoescpx to allow the newer cups-filters-1.0.24 driver to attempt to print.

edit: /usr/share/cups/mime/mime.convs
We only want pdf now, so prevent ps/ghostscript processing...
eg: #application/postscript application/vnd.cups-postscript	66	pstops

edit: /usr/share/cups/mime/cupsfilters.convs
comment out all filters under the heading "# PostScript filters"; that's pdftops, pdftops, pstops

do in a shell:
/etc/rc.d/rc.cups start

lpr -P printToFile stripe.ps

So, now, the results of all this is an Epson printer file dumped in the temporary directory. I have to use root to view it, or do a chmod... but it does dump it!

But it isn't the cups universal raster file... So I was not sure if there was an easy way to figure out where the problem was;

After studying the source code of the cups-filters-1.0.24 for a while (and being disgusted at the replication of code, and the bugs copied...) I came up with a little gem which can be used in the printer driver to dump the raster file's converted contents to a grayscale portable pixmap;
The image can then be viewed to graphically debug the source code...

Inside the pdf filter source code, there is a file "cups-filters-1.0.24/filter/rastertoescpx.c"

At around line 1610(+- 10 lines) but immediately after

> case CUPS_CSPACE_CMYK :
>	PrintOnce( "CUPS_CSPACE_CMYK\n","");
>        cupsCMYKDoCMYK(CMYK, PixelBuffer, InputBuffer, width);
>	break;
>  }

I add this source code;
 // Dump a pixbuf crude grayscale...
  {static int o=0;
   static FILE* pixdump;

   if (!o) {
	   pixdump=fopen( "/tmp/pixdump.ppm", "w" );
	   fprintf( pixdump, "P5\n#\n%d %d\n255\n",width, header->cupsHeight );
	   o=1;
   }

   for (int scanPixel=0; scanPixel < width; ++scanPixel ) {
	fputc( (255 - ((char*)InputBuffer)[ scanPixel ]) , pixdump );
   }
  }
// End of Andrew's kludge...

This snippet, with at most a change of variable names ought to be usable in any print driver; whether Hp, Epson, etc.

In a stupid replication of effort, every print driver converts the raster file from cups (any number of formats) into a CMYK format with varying numbers of color ink cartridges (somtimes no C, sometimes 2 C's, etc.)

Now here comes the fun part... (I'm actually getting somewhere!)
My print driver *is* receiving the image when I try to print *some* documents, but not others.  For example, the printer menu in the web browser -- "print a test page" *doesn't* work -- but shell command "lpr -P printToFile  fuoh-bar.jpg" does work.

I'll fix those another day.... just use the ones that work for now .... *BUUUT* the print driver does not appear to be correctly printing these images on the Epson R200.

I've noticed that:  The conversion to CMYK is doing really gross things like taking a black and white GIF image, and turning it into CMY -- but no K.  (Wastes a lot of more expensive ink...etc.)  There are a few other real perverted things going on -- but none should stop the image from being printed.

The only thing I see that's a show stopper is that all conversion is to a CMYK format, and not a CcMmYK format (my printer is 6 ink cartridges.);  That has to be a .ppm file issue, so what do I change to get all 6?






More information about the cups mailing list