Should the CUPS Raster output deviceofGhostscript output compressed or uncompressed Raster data?

[Heino Goldenstein]

Hello,

Johannes Meixner wrote:

> 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

we are working against
http://www.cups.org/documentation.php/doc-1.4/spec-raster.html

> what "the raster format is updated from time to time" actually means.

Updating the raster format has to mean adding a new version specification
including a new different "synchronization word".

> If "updated" means that all old versions are still supported

Old version specifications will not be vanish and not updated
software will still use them.

> (i.e. full backward compatibility) it is o.k. - otherwise not:

If you add a new version there is no reason to remove support
for the other ones. It is only a new version how to interpret
the data. And there is not even a reason why it has to be in
any way compatible to the other versions.

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

As the printer can not know which cups-raster version is send
in the data stream, it has to use the "synchronization word"
to determine how to interpret the data.

> 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

If it uses the current versions it should. If it wants updates
it should define a new version and can do what ever it wants.

> 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".

It is in status "RESOLVED WONTFIX" because there are no
comments about that this is the way to go, and a patch
ever has the chance to be accepted. Further I am looking
for pointers how to implement it in the right way (tm).

> For future I like the idea very much that printers should accept
> particular standardized CUPS raster format(s) as input format.

There are allready 3 cups-raster versions defined.

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

If a printer uses native cups-raster format you can not require
to use only one version. You have to support all of them to be
able to take the data from different sources independent of the
used version. It is like ghostscript, if there is a new
postscript level, it does not stop to be able to interpret
the previous ones.

Kind Regards
Heino Goldenstein