Currently we use a very basic PostScript printer driver for printer redirection in rdesktop. This unfortunately means that we cannot support fancy features like control of colour mode, duplex printing or other settings the printer might have. Supporting every possible setting the printer might have is not possible without abandoning the principle of a single printer driver. But we could try to support a few more of the standard features. One solution to this might be to implement XPS support (bug 3804). Another is to have a more competent PostScript driver. The latter could be done by shipping a PPD in wtstools (the actual driver is included with all versions of Windows).
Microsoft's PostScript driver is documented here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff556561%28v=vs.85%29.aspx PPD specification: http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf The above includes a list of standard options that we could include.
Also see bug 4362.
Created attachment 482 [details] msgenbw.ppd Microsoft's "generic" PostScript PPD (B/W).
Created attachment 483 [details] msgencol.ppd Colour ditto.
I can't find any explicit list of versions of Windows that includes their PostScript driver. But since they still have updated development pages up, I'd wager it's available on all current versions of Windows.
We might need to read the options out of the PostScript from rdesktop and convert them to command line arguments. See this patch from debian/ubuntu: * debian/patches/read-embedded-options-from-incoming-postscript-and-add-to-ipp-attrs.dpatch: Make CUPS reading all option settings in PostScript print jobs and add the option settings to the filter command line before starting the filter chain. This fixes the problem that in the PDF printing workflow (where incoming PostScript gets converted to PDF by pstopdf) option settings embedded in the incoming PostScript code do not get obeyed. Especially the options of jobs from Windows clients get ignored. We can't assume that the local cups has this patch applied.
Another interesting problem is printer settings. Driver queues are created and destroyed with the session, so there is no easy way for the administrator to control the settings. RDP allows persistent printer settings by sending over a blob to the client and expecting it back on subsequent connections. We could exploit this is we can figure out the format of the blob and prepare one before connect.
The following standardised PPD fields could be of interest to us: - *InputSlot: Lower Middle Upper Manual Envelope LargeCapacity - *PageSize/*PageRegion: Letter Legal Tabloid A3 A4 A5 - *OutputBin: Upper Lower Rear - *TraySwitch: True False - *Duplex: DuplexTumble, DuplexNoTumble SimplexTumble None - *Collate: True False - *Sorter: True False
Missed one: - *ColorModel: CMYK Gray Possibly also: - *Resolution: 150dpi 300dpi 600dpi 1200dpi
rdesktop (and associated tools) is being removed from the ThinLinc product.
