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

[Johannes Meixner]

Hello

On Jul 7 14:28 Michael Sweet wrote:

> On Jul 7, 2010, at 1:34 PM, Till Kamppeter wrote:
>> ...
>> I also suggest to either add a PPD extention to select CUPS Raster v2
>> output or to output CUPS Raster v2 in the case that there is no filter
>> afterwards (final format is CUPS Raster). As IPP Everywhere defines CUPS
>> Raster as a standard input format for printers, there will be more CUPS
>> Raster printers in the future. So we will need support for compressed
>> CUPS Raster.
>
> Just to be clear: IPP Everywhere hasn't even been approved
> as a PWG project yet and nothing in the introductory slides
> is set in stone (including file formats...)

When I read
http://www.cups.org/documentation.php/doc-1.4/api-raster.html
--------------------------------------------------------------------
The CUPS raster API provides a standard interface for reading
and writing CUPS raster streams which are used for printing
to raster printers. Because the raster format is updated from
time to time, it is important to use this API to avoid
incompatibilities with newer versions of CUPS.
Two kinds of CUPS filters use the CUPS raster API - raster
image processor (RIP) filters such as pstoraster and
cgpdftoraster (Mac OS X) that produce CUPS raster files
and printer driver filters that convert CUPS raster files
into a format usable by the printer. 
--------------------------------------------------------------------
I do not understand how currently CUPS raster data could
be used as a input format for printers at all?

As far as I understand the above CUPS raster API documentation,
the CUPS raster format can be currently only used on one same
machine where both kind of filters (those which produce CUPS
raster data and those which consume CUPS raster data) use the
same CUPS raster library functions (cupsimage) to make sure
that the actual particular CUPS raster format doesn't really
matter for the filters because it is encapsulated by the
CUPS raster library functions.

In particular - as far as I understand it - the current CUPS 1.4.4
implementation of the CUPS raster data compression in CUPS'
filter/raster.c source file looks like a CUPS-specific implementation
of a compression algorithm which might change at any time in any way.
Currently there is this comment in filter/raster.c
---------------------------------------------------------------------
.... compressed output is generally 25-50% smaller
but adds a 100-300% execution time overhead ...
---------------------------------------------------------------------
which seems to indicate even more that the actual compression
might be changed in the future perhaps regarding better compression
or regarding less execution time overhead or whatever else
(e.g. compression plus encryption to be sent via network socket
directly to a printer without an additional encryption protocol).

In the end what I like to point out is that currently I still think
that it would be best (in particular to be future-proof) to let the
rastertoidol filter do the compression to make sure its compressed
output is exactly the data format which the IDOL printer needs.


For future I like the idea very much that printers should accept
a particular standardized CUPS raster format as input format.
But I think this needs some discussion - in particular with all
kind of printer manufacturers - not only for printers for rough
industrial use but also e.g. for those "weak and cheap" printers
for home use where each cent of the hardware costs matters.


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