[cups.general] Should the CUPS Raster output device ofGhostscript output compressed or uncompressed Raster data?

[Johannes Meixner]

Hello,

On Jul 13 13:03 Heino Goldenstein wrote (shortened):
>
> There has not to be only one version specification. The infrastructure
> to support more versions is allready there. Let the printer decide
> which it will support. There is the "synchronization word" to let
> the printer make a relayable decision.
> The only missing part is the possibility to select the cups-raster
> output version to use in the ppd for the printer.

I may have misunderstood in
http://www.cups.org/documentation.php/doc-1.4/api-raster.html
what "the raster format is updated from time to time" actually means.
If "updated" means that all old versions are still supported
(i.e. full backward compatibility) it is o.k. - otherwise not:
If there was an incompatible change in the raster format,
it would not work to use one CUPS raster API implementation
on one machine to let it produce a raster format which
is incompatible to the raster format which is consumed
by another CUPS raster API implementation on another machine.
I.e. the crucial question is whether or not the raster format
is an implementation detail of the CUPS raster API.

Provided CUPS raster format stays full backward compatible
then there is _currently_ still the above "only missing part"
which seems to stay missing for some time as long as
http://bugs.ghostscript.com/show_bug.cgi?id=689885
is in status "RESOLVED WONTFIX".

For future I like the idea very much that printers should accept
particular standardized CUPS raster format(s) as input format.
But to make your printers work best right now, I still think
that _currently_ it would be best to let your rastertoidol filter
do the compression as you need it for your printers right now.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex