Hi, till recently we used the rastertohp filter to create ppds. But to be able to support all features of cups-raster, and to prevent an extra layer of recoding in an cups-filter, we implemented an emulation in our printer language (IDOL) to interpret the cups-raster-file-format native. For an example see rastertoidol and mps33e.ppd. The ghostscript cups-raster driver output is currently hardcoded to raster version 3. Because of the uncompressed image data, larger pagesizes (e.g. 17" x 24" at 300dpi monochrome) require relative large bandwith for the transfer from the CUPS server to the printer even if the page contains only few monochrome information. With the attached gdevcups.c.cups_raster_write_compressed.patch the cups-raster driver is hardcoded to output compressed raster version 2. Depending on the contend of the pageimage (e.g big dithered areas result in larger compressed data then even uncompressed) it would be better to have an option in the ppd to be able to select the cups raster write mode on demand. In respect to interoperability with other cups-filters the one-line patch is even a dirty hack. An ppd option solution would not impact any other devices. Do you have any thoughts? Many thanks in advance. Heino
Created attachment 4084 [details] rastertoidol cups-raster to IDOL filter
Created attachment 4085 [details] mps33e.ppd example ppd for new printer
Created attachment 4086 [details] devcups.c.cups_raster_write_compressed.patch dirty hack patch to verify functionality
I am not sure what the reporter is asking for - if he is asking if the hack CUPS_RASTER_WRITE/CUPS_RASTER_WRITE_COMPRESSED will break other cups devices, I don't think anybody is spending any time doing that test. As for make it possible to do compressed raster version 2 and for making it runtime selectable, the cups device supports a "cupsCompression" option, which can probably be used for that purpose, but it does not seems to be hooked up to any internal machinery at the moment. The pdftoraster tool seems to run with -dcupsCompression=... The original reporter is well-comed to submit a well-tested patch, but until then, it is unlikely for anybody to be spending much time on this request. Please re-open if such a patch is available. Till : can you comment on what the cupsCompression option does (and whether it has any effect)?
Till : can you comment on what the cupsCompression option does (and whether it has any effect)?
Hin-Tak, what is asked for here is whether the CUPS Raster output device should generate the uncompressed CUPS Raster format or the compressed one. I have forwarded this question to the CUPS mailing list for discussion now.
Hi, to explain the request a little bit more: This is the situation now for e.g. ps data and PCL printer: ---------------------------------------- | --------------- ------------- | --------- ----> || pstoraster | -----> | rastertohp || -------> | Printer | print || (cups-raster) | ver. 3 | (PCL) || ethernet | (PCL) | data || ver. 1 or | | generate || link to --------- || ver. 2 or | | Page- || printer || ver. 3 | | Description || | --------------- ------------- | PCL-stream | CUPS-SERVER | ---------------------------------------- As pstoraster and rastertohp reside on the same host cups-raster version 3 is the right thing to do (tm). Compression in pstoraster and decompression in rastertohp as interchangeformat (cups-raster version 2) will decrease the performance since the connection between the both drivers should be reasonable fast. The PCL-stream can be compressed to get the best performance over the ethernet link. This can be controlled for rastertohp with the "cupsCompression" parameter in the ppd. This is our situation for e.g. ps data and IDOL-Printer with cups-raster emulation: Since the rastertoidol script is mainly only a copy operation of the cups-raster data, the data is transferred over the ethernet link as is. For large pagesizes the ethernet bandwith is an aspect for the performance. So the right thing to do (tm) here is to use cups-raster version 2. The code to do this is already there. To prove this I created the patch in comment#3. ------------------------------------------ | --------------- --------------- | --------------- ----> || pstoraster | -----> | rastertoidol || -------> | IDOL-Printer | print || (cups-raster) | ver. 2 | (cups-raster) || ethernet | (cups-raster) | data || ver. 1 or | | cat "FILE" || link to | ver. 1 or | || ver. 2 or | --------------- | printer | ver. 2 or | || ver. 3 | | | ver. 3 | | --------------- | --------------- | CUPS-SERVER | cups-raster-stream ------------------------------------------ ^ | *.ppd ---------------------------------- | ... | | *cupsRasterWriteCompressed: True | | ... | ---------------------------------- Because the hardcoded value for the cups-raster format only either the IDOL-Printer or the rastertohp will be working at best performance. The right thing to do (tm) here is to have a parameter defined for the ppd to be able to set it for the requested printer. Since I don`t know the source of the ghostscript code very well I started this RFC to get any pointers how to start, but there was no response till now. Maybe it is even better to have a parameter to set the used cups-raster version. So the only missing part is having a ppd parameter and make the line from the patch in comment#3 depending on it. The default has to be set to output cups-raster version 3. Do you have any thoughts? Many thanks in advance. Heino
Fixed in SVN rev 11508. Please test. By default, nothing changes, the "cups" output device produces uncompressed CUPS Raster version 3 output. This way we are backward compatible. If you want to have compressed CUPS Raster version 2 output, for example for a native CUPS Raster printer, add the line *cupsRasterVersion: 2 to the PPD file (if you edit the PPD file in /etc/cups/ppd/ for testing, do not forget to restart CUPS). This should not only help for your printers but also for the case that the planned IPP Everywhere standard will support CUPS Raster printers.
I have not a current development environment for ghostscript set up, so I have ported your changes of gdevcups.c back to the version I used while doing my investigations (see: ghostscript-cupsRasterVersion.patch). All tests done till now are working as expected. As you can see by the file sizes it makes quite a difference if compression is used or not. -rw------- 1 lp lp 547281 Jul 16 09:47 testpage-A4-600dpi.cups-raster-v2 -rw------- 1 lp lp 4352362 Jul 16 09:50 testpage-A4-600dpi.cups-raster-v3 Now I can include the line: "*cupsRasterVersion: 2" in our ppds as old versions will silently ignore it and if ghostscript 9.0 will be released the right things will happen without further intervention. Compatibility is preserved in all combinations, old versions will continue to work with which ever cups-raster version is used and if cups-raster version 2 is selectable it will be used. In worst case scenarios, where compression deliver bigger sizes than uncompressed, it is possible to modify the line to use cups-raster version 3. As I did not know the internals of the code base well enough I could not come up with a patch from scratch. Thank you very much for implementing this.
Created attachment 6495 [details] ghostscript-cupsRasterVersion.patch
Heino, this will now only accelerate printing PostScript and PDF files under Linux. If you want to directly print images to CUPS, the imagetoraster filter is used instead of Ghostscript. So you need to ask the CUPS project (http://www.cups.org/str.php) for compressed CUPS raster support in imagetoraster.
Till, I am aware of this. But printing photorealistic images on a black and white printer will end up in a dithered raster image. For the used compression algorithm a chessboard pattern is a worst case scenario where the compressed data is even bigger than the uncompressed data. I like to do some investigation before I file the RFE to be sure it is really an enhancement and will not turn into a regression. Maybe the best thing to do is to stay allways with uncompressed data for image printing. For PostScript and PDF this is no problem because pure photorealistic image printing is usually a corner use case. The main page content is like the CUPS test page (document printing) where the compression does a good job. If my understanding is right, the *cupsRasterVersion attribute can only changed by modifying the ppd. Maybe it is even better to have something like this in the ppd: --- *OpenUI *Datatransfer: PickOne *OrderDependency: 10.0 AnySetup *Datatransfer *DefaultDatatransfer: Compressed *Datatransfer Compressed/Compressed: "*cupsRasterVersion: 2" *Datatransfer Uncompressed/Not Compressed: "*cupsRasterVersion: 3" *CloseUI: *Datatransfer --- The default can then be set to the main use case and the corner case can be selected on demand. But I don`t know if this is possible.