Monday, August 06, 2012 9:45 AM
For example, in completePrintCapabilities function we add the "psk:ReversePortrait" option to "psk:PageOrientation" feature, because otherwise this option is unsupported in GPD.
To support persisting this option to DEVMODE we also implement convertPrintTicketToDevMode and convertDevModeToPrintTicket functions, where we save and restore the setting for the "psk:PageOrientation" to and from the DEVMODE Property Bag respectively.
Everything works fine except the case when there is no desktop printer extension installed on the user's computer. In this case the standard desktop "Printing preferences" UI is shown to the user, but changing of the Orientation setting through this standard UI does not have any effect.
I found that this happens because the system behaves differently for the cases when Printer Extension is installed and when it is not. For the case of Printer Extension installed, the system calls convertDevModeToPrintTicket before showing the Printer Extension UI to the user, then shows Printer Extension UI with the resulting PrintTicket and then, after user pressed "OK" and Printer Extension committed changes to Print Ticket, it calls convertPrintTicketToDevMode to save Print Ticket changes back to private part of DEVMODE (I'll refer to it as DEVMODE_private later).
However for the case of the standard UI, the system seemingly does not use the "DEVMODE_private->PrintTicket->DEVMODE_private" path and saves the orientation setting directly to the public part of DEVMODE. This causes the setting from DEVMODE_private part to always overwrite the setting from the public part whenever convertDevModeToPrintTicket is called (for example, when printing, or opening default Printing preferences).
Could you advise how can we solve this problem?
- Edited by kondakovdmitry Wednesday, September 26, 2012 6:19 AM
Monday, August 06, 2012 6:27 PM
The standard print UI doesn't use PrintTicket, so there's no PrintTicket available to convert from in that scenario. We expressly do not recommend that you add features using JS constraints since they don't affect the standard UI. I understand that, in this case, the ReversePortrait feature isn't supported by GPD, however, our recommendation stands that you should not add features in this way if you expect them to be configured by the standard UI.
Why is ReversePortrait an important scenario for your customers? There may be a more reasonable way to deliver the functionality to your users.
Wednesday, August 08, 2012 9:01 AM
Thank you for the answer.
We just had ReversePortrait option in our V3 driver where it worked well and wanted to support it in our V4 driver as well. We do not expect this option to be available from the standard UI, but we wanted it to be available in our Printer Extension and we wanted to keep Print Ticket pretty much the same as in V3 driver.
There is also another such feature - Duplex, for which we had our custom "ns0000:PrinterDefault" option in Print Ticket in V3, which is unsupported in GPD. For this feature in V4 we now use different name in GPD ("DocumentDuplex" instead of the standard "Duplex") to be able to add "PrinterDefault" option, but this causes other problems, like the one that "Printer properties" shows that our printer does not support Duplex.
So, as I understand your recommendation, you state that JS constraints should not amend existing GPD features, right? How then can we support options like ReversePortrait for Orientation and PrinterDefault for Duplex?
Wednesday, August 08, 2012 5:02 PM
Dmitry, Thanks for explaining further. I understand the scenario you're trying to deliver, but I'd recommend that you simply not do either of those in v4. V4 is a new driver model, and not all scenarios will be supported in the same way they were before. For your specific question, JS constraints are very good for adding things like ParameterDef/Inits, and nested features (eg N-Up's PresentationDirection), but when you add additional options to standard features in the JS constraints, the scenario breaks down in several places.
Monday, August 13, 2012 1:46 PM
Thank you for clarification.
I understand, that V4 is a new model, but I don't completely understand why adding options to standard features is such a problem in V4.
As far as I know, the standard Metro UI does not have such problems and works well with added options. What really makes it difficult to make the standard desktop UI act the same way?
If the standard UI were just a special case of normal "printer extension" using the same PrintTicket-based interfaces, then probably there would be no such problems as I described in the beginning of this thread.
You know, that there are also other problems like the problem with wrong page orientation when printing from Adobe Reader with the standard UI which does not occur when any printer extension is installed for the printer (we filed a bug to Microsoft [REG:112080764504952])? I guess that the current design of the standard UI might be somehow related to the root cause here as well.
Anyway, I might be wrong since I do not know the internal details here. Probably the current design is the best possible considering all the implications, or you may be planning to replace the standard UI by something more fitting to the new V4 model in future releases of Windows.
Anyway, I feel that the V4 is a step forward.