The server-to-client part of this bug is fairly easy: We should add support for checking the printer name in the LPD protocol. If no printer name is included, we should printer to the default printer just as before, but if a printer is defined, we should use it instead. This means that on Windows, we should call SumatraPDF with "-print-to <printer-name>" instead of "printo-to-default". Similar for other platforms. This change could even go into 4.1.1. One the server side, we can create a second queue "bonprinter" (as outlined in Issue14527), which includes this printer name in the LPD request. Either use the same thinlocal backend, or make a copy of the backend. It might even be possible to tweak our backend and/or scripts to that if you create a thinlocal printer with a different name, that name will be sent to the client. Thus, the customer would not need to run a modified product; it would be sufficient to manually add a second thinlocal printer. As bug 2761 points out though, transferring the queue name over IPP might be somewhat tricky.
We also need to consider what happens when an unknown printer name shows up. The obvious solution might be to just steer it to the default printer. That might not be the best precedent though once we have full support for multiple local printers. At that point you might want to throw up an error since the client and server should be in sync with regard to printers.
Server side solution: - Enable thinlocal to use queue name when job is sent to the client. - Add custom IPP option when job is respooled with origin queue name (queue name on master) - Make use of custom queue name option if exists. Fixed in commit 29018. Verified and working on CentOS EL6 with cups v1.4.2. Also verified that the lpd client is passing the correct queue name to ThinLinc client using tcpdump on the client side. Summary, the queue name passed to thinlinc client is the name of the queue in cupsd, except for when an agent is receiving a respooled job, the queue name is the name of the queue on master.
Let's log queue name in tlclient.
(In reply to comment #5) > Let's log queue name in tlclient. Fixed in commit 29024.
Nearest is broken: > D [05/Sep/2014:11:01:02 +0200] [Job 1] Traceback (most recent call last): > D [05/Sep/2014:11:01:02 +0200] [Job 1] File "/usr/lib/cups/backend/nearest", line 108, in <module> > D [05/Sep/2014:11:01:02 +0200] [Job 1] sys . exit ( ooO00oOoo ( ) ) > D [05/Sep/2014:11:01:02 +0200] [Job 1] File "/usr/lib/cups/backend/nearest", line 86, in ooO00oOoo > D [05/Sep/2014:11:01:02 +0200] [Job 1] OoooooOoo [ 0 ] ) > D [05/Sep/2014:11:01:02 +0200] [Job 1] TypeError: respool() takes exactly 4 arguments (3 given)
(In reply to comment #7) > Nearest is broken: > > > D [05/Sep/2014:11:01:02 +0200] [Job 1] Traceback (most recent call last): > > D [05/Sep/2014:11:01:02 +0200] [Job 1] File "/usr/lib/cups/backend/nearest", line 108, in <module> > > D [05/Sep/2014:11:01:02 +0200] [Job 1] sys . exit ( ooO00oOoo ( ) ) > > D [05/Sep/2014:11:01:02 +0200] [Job 1] File "/usr/lib/cups/backend/nearest", line 86, in ooO00oOoo > > D [05/Sep/2014:11:01:02 +0200] [Job 1] OoooooOoo [ 0 ] ) > > D [05/Sep/2014:11:01:02 +0200] [Job 1] TypeError: respool() takes exactly 4 arguments (3 given) Fixed in commit r29327.
Works well, when printing to thinlocal, the queue name is printed in tlclient.log. Also verified that printing to nearest still works. Tested using build 4496.
