[Openicc] cupsICC on remote CUPS servers Part 2

[Robert Krawitz]

On Sun, 22 May 2011 00:20:54 +0200, Jan-Peter Homann wrote:
> Content-Transfer-Encoding: 7bit
>
> Hello edmund and all,
> I would prefer, that administration of server side print setups and associated profiles is done on the server. All clients printing to the server should than always be able to work with the actual server setups without any needs to update setups on the client side.
>
> Otherwise it makes no sense to use the term server.
>
> if we do colormanagement on the client side, than it should be done completly there including administration of all printing setups and profiles and screening through the driver.

GNOME-Print used this architecture (do everything on the client).  It
has a number of problems:

1) Network traffic bloat: the raw printer data stream can be much
larger than the source.  For example, printing a large page at very
high resolution (say, 5760x2880) on an Epson printer can generate
hundreds of megabytes of data, while the source image is likely 10 MB
or thereabouts.

2) Some printers are timing-sensitive and have a bidirectional
protocol with the host (I recall some old cheap laser printer that
needed very precise timings with the host, or it might overheat
dangerously).  If the client is in charge of the data exchange, the
network latency and unpredictability might cause problems.