Should the CUPS Raster output device ofGhostscript output compressed or uncompressed Raster data?

Heino Goldenstein heino.goldenstein at microplex.de
Tue Jul 13 13:03:03 PDT 2010


Hello

Helge Blischke wrote (shortened):

> Johannes Meixner wrote:
>
>> Hello
>>

--8<--

>> 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 I wrote in an earlier post: If you have one of our printers
they are since mid 2008 capable to provide the cups-raster
emulation. If the emulation is selected, you can send them
cups-raster v1, v2 or v3 data and it is printed.

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

Why have they to be on the same maschine?

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

Why then need an Application Program Interface?

The cups-raster versions are specified in the reference. If both
parts comply to the specification they should work.

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

Then there has to be a new version 4 specification in the reference.

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

But cups-raster v2 specification still exist.

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

The IDOL-printer needs cups-raster v2 in this case.
And as pointed out by Till Kamppeter it is even possible to
eliminate rastertoidol alltogether.

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

Our printers do since mid 2008 support all till now specified
cups-raster versions.

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

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.

>> Kind Regards
>> Johannes Meixner
>
> The filter/raster.c reveals that compressing the raster data forces version
> 2 to be used. The (new ?) version 3 format provies no compresseion method
> according to the documentation but provides (according to a quick look at)
> more methods to specify and code colors.

IMHO the only difference between v2 and v3 is the compression.
So, if you want compression select v2, if not select v3.
If you want not jet specified new features, select v4 ;-)

> And, for CUPS internal use (between filters of filter to backend)
> compression does not make too much sense, especially on systems which
> implement pipes between processes via shared memory, which reduces the
> transport to switching pointers around...

And, for CUPS external use (between backend and printers) compression
make much sense. For a 142 page per minute printer at 600dpi uncompressed
raster data takes a huge bandwith.

Kind Regards
Heino Goldenstein





More information about the cups mailing list