[cups] Linux->(Linux, Windows) printer sharing with drivers on the server

[Ivan Shapovalov]

On 2016-05-19 at 16:01 +0200, Johannes Meixner wrote:
> Hello,
> 
> On May 19 16:24 Ivan Shapovalov wrote (excerpt):
> > On 2016-05-19 at 15:11 +0200, Johannes Meixner wrote:
> > > 
> > > Usually when printing from a Linux client with CUPS
> > > to a Linux CUPS server, no driver is run on the client,
> > > see "Differences in Printing between Windows and Linux" at
> > > https://en.opensuse.org/SDB:Printing_from_Windows_to_Linux
> > 
> > Yes, I understand this, and this is exactly what I want.
> 
> As far as I understand your initial posting
> -----------------------------------------------------------
> ... the clients should use a "generic postscript" driver
> (not a raw queue) and send postscript to the server,
> -----------------------------------------------------------
> you want to somehow enforce from the Linux CUPS server
> that the Linux clients use a "generic postscript" driver.
> 
> This is not what is described in
> https://en.opensuse.org/SDB:Printing_from_Windows_to_Linux
> -----------------------------------------------------------
> With UNIX/Linux printing, client systems send the
> original data (plain text, PostScript, PDF, or JPEG)
> to the CUPS print server,
> -----------------------------------------------------------

There are four possible configurations for remote printing with cups:
0. Do not run cupsd on client, connect directly to cupsd on server
   (ruled out because it is too invasive)
1. Use printer-specific driver on client and "raw queue" on server,
   send printer-specific data
2. Use "raw queue" on client and printer-specific driver on server,
   send application-specific data (read pdfs)
3. Use generic postscript driver on client and printer-specific
   driver on server, send postscript

Windows->Windows does (1). The article suggests (2). I want (3) for
performance reasons.
CUPS does nothing of this: by default (with clueless user), it tries to
use printer-specific drivers _both_ on server and client!

That's why I said "this is what I want": if I make cups do at least (2)
by default, this would be better than nothing.

> 
> As far as I know there is no way how to enforce from a
> CUPS server that its clients use a "generic postscript"
> driver (or any other kind of driver).
> 
> As far as I know clients can basically send whatever
> they want to a CUPS server and when the CUPS server
> does not know how to deal with a particular data type
> the CUPS server may reject or ignore such data
> or fall back to raw printing or whatever else
> depending on how the CUPS server is configured.

Correct; but there is a kind of auto-detection (guesswork) at client
side. I want to convince that auto-detection to pick postscript driver
by default.

IIUC, it is based at matching "make / model" against installed drivers.
Probably it is possible to spoof advertised "make / model" so that it
would match the generic postscript driver? Or maybe there is some
obscure tag in the dns-sd record which convey that information to the
client?

> > I'm seeking advice on how to convince auto-discovery
> > to work this way.
> 
> I think this is not possible (as far as I know).
> 
> Note that it is called "discovery" which means only
> discovery of remote print queues without any kind of
> "from-server-enforced-client-configuration".
> 
> Unless someone else posts here a way how one could
> set up "from-server-enforced-client-configuration"
> on a CUPS server, I assume all you can do is
> to use a sufficiently powerful machine which
> can work as usual CUPS server.

This won't help: as I said, by default CUPS does strange things which
do not even remotely work, due to absence of printer-specific drivers
on client.

Thanks,
-- 
Ivan Shapovalov / intelfx /