We have a problem now where we can show a native Page Setup dialog (pending patches in bug 36796), which, on Mac, gives us a native print record that we can feed into the printing dialogs. This specifies things like paper size, orientation, and possibly other driver-specific settings. However, we currently don't make any attempt to update nsIPrintOptions with the data in the native print record, and nsIPrintOptions duplicates some of these options (like orientation, paper size). This means that things like Print Preview will not correctly show the orientation that the user selected in the Page Setup dialog, which is wrong.
Now that I'm trying to implement Page Setup on Mac OS X, I can see that our application-global nsIPrintOptions service prevents us from using the printing session APIs in Carbon. This means that we won't be able to support multiple simultaneous print sessions (like the user printing from two browser windows at the same time). We really need nsIPrintOptions to be per-browser window.
Reassigning to Rod
We have the nsIPrintSettings interface for the per browser window print "options" The print interface will be changnig to accept this as the arg instad of nsIPrintOptions (which will be for internal use only)
nsIPrintSettings is currently totally unused. Are you sure that this is what it's for? Also, be aware that there is duplication of data between the native print settings record on Mac (a TPrint, or PMPageFormat), and the fields in nsIPrintOptions/nsIPrintSettings. In some cases, you may not be able to get information out of the native print settings to fill in nsIPrintOptions/Settings (e.g. for paper size). So what I'd like to see here is a solution that is savvy to the different ways that print options are specified on the different platforms, and a paring down of the APIs so that they only contain accessors for data that the layout engine actually needs to call for printing, rather than the current kitchen-sink approach. Also note that if you start storing page setup options on per-browser window basis, then we can start moving to the session-based Carbon printing APIs.
The PrintSettings is now being used on a Window by window basis. I am not sure what the "kitchen sink" approach is, please describe alternative approachs. Also, if there is duplication of data between the PrintSettings and the Mac Print record then there should be a bug file on the Mac not to do that and it should be assign to dcone and copy me. marking works for me.
This certainly isn't "worksforme". If anything, it's "Wontfix". And I'd rather not see that done until I see some evidence that someone has taken the time to study the Mac printing APIs, and determine how they fit into the XP print dialog world.
over to dcone