Microsoft's solution to driver-less printing via RDP is by sending XPS documents. This is very similar to how our thinlocal works. These days there is a libgxps library (written so evince can read XPS) that we could possibly use to add XPS support to rdesktop. It would probably make printing work a lot better from Windows machines.
Some backends for rendering: https://live.gnome.org/libgxps http://www.ndesk.org/Xps (C#) http://www.ghostscript.com/GhostXPS.html Protocol documentation: http://msdn.microsoft.com/en-us/library/cc242947.aspx
I did some quick tests by using Microsoft's XPS Writer printer: - Firefox, aftonbladet.se - Internet Explorer, msn.com - Adobe Reader, a complex PDF In all three cases evince displayed the files identical to how Windows does. evince-3.6.1-2.fc18.x86_64 libgxps-0.2.2-3.fc18.x86_64
Bah. Microsoft have avoided specifying a lot of the details by pretending that the RDP channel is just a transparent tunnel to an XPS capable printer driver on the client. So it seems that this function will not work with just any printer when using Microsoft's client. The details are probably available in the XPS/printer API documentation, but it makes things a bit more complicated to decipher. The good news is that it seems to be properly generic. XPS includes something equivalent to PPDs, and this is what RDP uses to exchange capabilities and print job options. The actual print job is sent over the standard printer redirection, but with a special flag indicating that it is XPS data. Not entirely clear where the job options are transferred. There are a bunch of calls to convert the XPS options to a DEVMODE blob, so it might be included that with the print job. On weird section are the messages to display a configuration UI. They indicate that the UI should be presented on the client, not the server. It has references to RAIL though, so it might only be relevant in that case.
rdesktop (and associated tools) is being removed from the ThinLinc product.
