If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

nsIPrintOptions needs to get settings from native print dialogs

NEW
Unassigned

Status

()

Core
Printing: Output
16 years ago
7 years ago

People

(Reporter: Simon Fraser, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
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
Assignee: kmcclusk → rods

Comment 3

16 years ago
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)
Status: NEW → ASSIGNED
(Reporter)

Comment 4

16 years ago
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.

Updated

16 years ago
Target Milestone: --- → mozilla0.9.7

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.9

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla0.9.7

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 5

16 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 6

16 years ago
verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

16 years ago
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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 8

16 years ago
over to dcone
Assignee: rods → dcone
Status: REOPENED → NEW

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla1.0

Updated

16 years ago
Target Milestone: mozilla1.0 → Future

Updated

16 years ago
Blocks: 125824
Assignee: dcone → nobody
QA Contact: sujay → printing
You need to log in before you can comment on or make changes to this bug.