We need to implmement page setup/print setup, store the users preferred printer settings etc.
This is a chrome issue... not sure who gets this..
Assignee: dcone → sfraser
So I take is support for saving the users's preferring Print Setup options is implemented? What are the API calls I need to make?
Assignee: sfraser → dcone
Print setup is currently platform specific. We are using the print dialogs supplied by the platforms.. except for GTK which Syd duplicated a generic Linux dialog for PostScript. I will support the API's which we come up with (margins, headers, etc, etc).
Assignee: dcone → don
Target Milestone: --- → M17
Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by 05/16 or we may pull this feature for PR2.
Whiteboard: [FEATURE] → [nsbeta2+][5/16][FEATURE]
I don't see why (as I wrote in bug 11767, which is also on don's list marked milestone Future) there can't be a cross-platform, XPIDL-defined interface to the platform-specific Print Setup code. Is that really don's job? Don, who is gonna do this? Do you need help? When I see SVG stuff going into the tree just before the feature freeze (and don't get me wrong, I like SVG -- but let some external-to-netscape.com hackers do it), while crucial, basic features are at risk, I start to get ornery. And nosey! Maybe, in absolute priority order, the cc: list of this bug should be helping with Print Setup and similar bugs first, then (if there's time) helping with SVG? /be
See Bug#17608. The correct term is "Page Setup".
Clayton, this isn't an XPApps task. We don't do platform-specific dialogs like this. I think dcone or a toolkit person needs to own this bug and bug #11767.
Assignee: don → clayton
Target Milestone: M17 → ---
Triage duty calls. Reassinging to av.
Assignee: clayton → av
On exception list for PR2, removing 5/16...giving [nsbeta2+]Exception Feature status.
Whiteboard: [nsbeta2+][5/16][FEATURE] → [nsbeta2+]Exception Feature
*** Bug 11767 has been marked as a duplicate of this bug. ***
Ok, There seems to be alot of confusion about what this bug means. The source of the confusion is there are two separate dialogs used to setup printing. a cross-platform page setup dialog where the user specifies margins, whether or not to print the background etc. a printer driver specific dialog that is provided by the printer manufacturer. This dialog is usually brought up using a button off the page setup dialog or it is displayed when the page is told to print. Given this: The cross-platform page setup dialog should be done in XUL and owned by either the XPFE or BROWSER teams. An API specifying the page setup settings needs to be added to the contentViewer, PresShell or other appropriate interface in layout. This should be owned by layout. An abstract Interface should be created for bringing up the printer specific device driver. This should should live in widget, and needs to implemented on each platform. So which of these parts does this bug cover? The description seems generic enough to cover all parts, but there are potentially three different owners for this problem. Thats why this bug keeps bouncing around. I think dcone should own the problem of creating the API's for both layout and widget and we should file a separate bug for the creation of the XUL page setup dialog. Does anyone disagree with this?
Assignee: av → dcone
That's an excellent analysis, and the bug, as filed, covers all parts. Feel free to break them out into separate parts.
Don Cone is currently working on the PrinterService + the API and the implementation for bringing up the Native PageSetup Dialog on the Mac. He should be able to checkin a first pass at the PrinterService and be able to bring up the Native PageSetup Dialog tommorow (6/22). This will provide no increase in functionality for the beta2 user. The PrinterService will hold the current print settings but it will have no effect on printing.
Deadline for exception features has passed, and PDT feels that we can ship Seamonkey without this feature. Maybe we can get to it for the next rev. Marking nsbeta2-
Whiteboard: [nsbeta2+]Exception Feature → [nsbeta2-]Exception Feature
This bug has been marked future because we have determined that it is not critical for netscape 6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Page Setup not critical? I'll be damned!
Keywords: nsbeta2 → nsbeta3
I hereby attach my concern. Every Mac application that prints has Page Setup. Mozilla prints. Therefore, Mozilla must have a Page Setup menu.
I have all the code ready to implement this.. when and if this changes. I agree with Simon and Pierre..
Cool... Changed milestone from Future to M18.
Target Milestone: Future → M18
Only problem is the PDT team will not approve this.. I worked on it.. got it almost ready.. they consider this a feature.. and said no! If we can convice to finish this.. then I can, until then.. its future.
Target Milestone: M18 → Future
I see an nsbeta3 keyword. Why can't the milestone remain at the next one after nsbeta2? Future is taken to mean (and used to mean) "not in netscape 6" or "not in the next major release" of mozilla.org-based code. Don, could you please attach your patches to get this almost ready? Then maybe someone not bound by pdt rules could finish it. That's worked time and again; attaching patches in progress to bugs is a Good Thing. Maybe we can get this in soon, with waterson or brendan approval and your code-review approval, if some non-netscape.com contributor picks up the ball.
CCd phil for re-evaluation since he's the one who wrote that "PDT feels that we can ship Seamonkey without this feature". This can't be a Future bug. I don't understand why PDT refused dcone's fix.
Marking in nsbeta3-
Whiteboard: [nsbeta2-]Exception Feature → [nsbeta2-][nsbeta3-]Exception Feature
Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the queries don't get screwed up
Removing future/beta3- for reconsideration, per jar and michaell at the "Mac sucks" meeting.
Whiteboard: [nsbeta2-][nsbeta3-]Exception Feature → Exception Feature
Target Milestone: Future → M18
FWIW.... during the mac meeting today it was asserted that this was completely done, and a patch was in hand, and that Phil had insisted that the fix not be checked in. Reading the comments above from dcone (who would have authored the bulk of this feature), the statement made was that this was "almost ready," and that he stopped working on it because it was considered a feature. (He also said that it "all code was ready to implement this" at an earlier point, but the last position statement talked about getting permission to "finish it" as well). As I read the comments, it was an incomplete feature, that would need to be finished, and was instead latered. Although this bug is currently listed as Mac System 8.5, I believe this is a XP feature defficiency. I think the feature didn't make the train on any platform, and now we're racing to make sure the train even runs at all on any tracks (platforms). Appology in advance to the folks that I misunderstood (either dcone above, or the mac folks at the meeting today)... but I'd be happy to be corrected. I'd also note that it is very uncommon to not have a page-setup on most any platform... but I am curious to better understand why this issue is seemingly pivotal on Mac (certainly that was the sentiment expressed above). Hopefully the relative importance was caught in in the mac meeting today by Michaell as folks prioritized critical development work needed to better the mac. As one last comment, based on my memory of discussion of this bug... even after dcone finishes the infrastructure for this bug (back end work), there is a bunch of front end work (UI) to be done, as well as preference saving work to be tied in, and of course qa tests to be added for this area. Am I mistaken about that memory of "what it would take to land this feature?" Thanks, Jim
I think you have a good understanding of this bug. I have the bulk of the work completed communicate information between the page setup, preferences to the actual print job in an XP way. Most is even checked in.. I have to hook up the factories to finish this. The calling of the page setup dialog (Platform specific) and the filling in of the printer object would have to be done. Also the printer code would have to use these setting from this object.
Let me summarize the current state of this bug: Printer Service (Holds the current printer settings to be accessed from Layout, Preferences and UI) MOSTLY DONE Hook up layout to use settings in Printer Service (i.e print background, Margins etc.) NOT STARTED Create a dialog to let the user specify the settings NOT STARTED Bring up platform specific Page Setup dialog - (Mac is the only platform with a native page setup dialog. On WIN32 and Linux the page setup dialog is created by the application) NOT STARTED Save and Load printer settings from preferences NOT STARTED The Mac is unique in that some of the settings that are found in the printer dialog (The dialog brought up just before printing) are located on the Mac's page setup dialog instead. Most notably, page orientation. On WIN32 page orientation (landscape/portrait) is on the printer dialog so it is settable in the current build. On the Mac we are not able to set the page orientation because we would need to bring up the native Mac pagesetup dialog. As a partial solution we could implement a method on the PrintService to bring up the pagesetup dialog on the Mac. This would allow the user to set the page orientation. We would also need to create a PageSetup menu item which calls this method.
Added [NEEDINFO] to status. What is the minimal implementation for we can get away with? If we need a full page setup I'll have to nsbeta3- this bug. If we can come up with a subset, such as just bringing up the native pagesetup dialog on the Mac, we can probably get that in. CC'ing ekrock
Whiteboard: Exception Feature → [NEEDINFO]Exception Feature
This is an out feature, but you can do the subset, native page set up only on the Mac. Please see what Mac folks vote. If all say yeah! then putting in [nsbeta3+] for that.
Whiteboard: [NEEDINFO]Exception Feature → [nsbeta3+][nsbeta2-]Exception Feature
I *REALLY* don't see how netscape can ship without this feature and get away with it. In the beta's, yes. As a supposeably "finished" product, no. The press will have a field day. It's starting to get to the point where slipping the schedule a month will do LESS damage then releasing netscape 6 in a still very buggy and feature missing state. It's better to be considered "late" (which you ALREADY ARE, by idiotic people who can't wait 5 god damn minutes for ANYTHING) then to be considered "late AND buggy".
Whiteboard: [nsbeta3+][nsbeta2-]Exception Feature → [nsbeta3-][nsbeta2-]Exception Feature
My $0.02. <Rant> How exactly are we expecting *any* Macintosh user to use a browser that they can't print MapQuest (another of our brands, by the way) Maps from? 4.x had quite a few bugs that could be worked around by going into Page Setup and changing the Print Zoom to 75% instead of 100%. NS6 doesn't even have that, and quite frankly I can't print a page that is wider than a normal page. Its about 2.3 pages wide (horizontally) and its just cutting off whatever is to the right of the roght margin. No extra pages, nothing. The ideal thing is to put this page in Landscape Mode, but-guess what!-I can't! No Page Setup to do it in! Windows has the capacity to do this all in the print dialog, but on the Mac there is no other option. Off to print with IE. </Rant>
The more I think about it, the more it bothers me that 4.x had crappy printing on the mac, and that NS 6 has managed to do even worse. I'm upgrading the severity to critical because I can't see any reason why anyone in their right mind would bother to use our product while doing research (or map searching, or e-mail, or whatever) only to find out they can't print a thing on it properly. *Properly* being the key word here. Yes, I can get half a page. Great, but unless I'm psychic, I can't properly fill in the blanks. I'm sitting in my cube waiting for someone to smack me upside the head. Call me and I'll accomodate appointments.
Severity: normal → critical
Is there any low-hanging fruit here? Could we bring up only Page Setup, only on the Mac, using the native dialog, perhaps even disabling any settings that aren't easily supported? Are there any printer companies (cough HP cough) that might loan us an engineer to help with this? It is rather pitiful that we can prefill your spouse's mother's maiden name in forms, but can't print them. cc pinkerton, saari, danm, sdagley,scc
Adding shrir to the cc list
I really agree with the above few comments. Clearing status whiteboard for reconsideration.
Whiteboard: [nsbeta3-][nsbeta2-]Exception Feature
Adding nsmac2 keyword, since printing is important for Mac, and IE 5 currently beats us hands down here.
Would love to fix this, but there just isn't time before beta3. Added helpwanted keyword.
Are we really not going to fix this for rtm? Adding keyword, to get it on radar.
Created attachment 16871 [details] [diff] [review] Example patch to implement page setup. See comments below
The patch I posted implements the native Page Setup dialog for Mac. I only implemented the nsPrintOptions component registration for the Mac and Windows. The other platforms would have to be implemented, not a big task and not required to get the Mac native page setup working. Also the PrintOptions service needs to be registered.. and I registered this service in nsAppRunner.cpp..not sure if this is the appropriate place. This patch did not put them page setup menu item in apprunner..
This will need heavy review and super-duper approval, and probably should be trunk-tested before rtm-plussing to attract PDT consideration for N6. There is very little (if any) time left for that, but I think this is still worth the effort.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
Not to throw another hurdle into your way on this, but if you guys are serious about trying, then you'll need to talk to international. If you are adding a menu item and a complete dialog that hasn't been localized....Even if the dialog is native, the menu item will be a stickler. Just a bit of advice.
cc'ing folks on the xpapps team
I can probably add this. We already have a [disabled] Page Setup item, so this shouldn't be a problem wrt internationalization.
Marking rtm-. Getting off the rtm radar.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm-]
Interesting bug, so I'm cc:ing myself to this.
we should probably release note this since there is a menu item called Page Setup and it's always disabled. I really wish there were some way to print at a smaller percentage or change the orientation. These are commonly used, expected behaviors that affect dogfood usage so I'm adding that keyword too in case it's relevant beyond rtm. Removing old keywords nsbeta2 and nsbeta3 and nsbeta3- from status whiteboard.
Keywords: nsbeta2, nsbeta3 → dogfood, relnoteRTM
OS: Mac System 8.5 → All
Whiteboard: [nsbeta3-][rtm-] → [rtm-]
Adding to Composer section of Release Notes, and would appreciate help on the writup: Is this truly a problem on all platforms, as indicated in the Platform category, or just the Mac, as the bug comments seem to indicate? Any workaround info that we can provide?
This is just a Mac problem. The biggest problem with this bug will be that Landscape will not be an option.. I will look for workarounds today and will update this bug.
Hardware: All → Macintosh
Why is this a Mac-specific bug? Page setup is not available for me on Linux either (the menu item is always disabled). Don Cone--why is landscape special? What is the problem with it? Is the above patch checked into the trunk?
*** Bug 60475 has been marked as a duplicate of this bug. ***
Page setup is also not available on Windows 2000 and Windows 98 (Trunk build 2000111604)
Removing myself from list of cc's.
Mac builds need this implemented because currently there is no option to match the window width to the printed page. I hate to have web page print outs chopped off at the edge and lots of nearly blank pages printed out afterwards. This is THE reason I can not use Mozilla for my regular work.
I took a time today to read all the comments in this bug. I just can not believe PDT is blocking this from getting fixed. If it wants itself to claim a usable browser, Mozilla needs this implemented to print the window fit into a page. Why is it unnecessary to implement a functionality that simply matches NS4.5-4.7? I can not see any point there. If internationalization is a potential problem, fine that can be addressed in relnotes, although I very much doubt it matters at least in Mac, because the dialog called is in the System extention and handled by OS.
Since we seem to have a prototype ready, nominating for beta1.
Keywords: dogfood, rtm → mozilla0.8, nsbeta1
Hardware: Macintosh → All
I am wondering if the default page size is set for US letter or not. Here in Japan and a major part of the world, A4 letter is the default. Maybe most of you are not experiencing the problems I see because of that. That may explain the lack of enthusiasm here, which, if truly the case, is WRONG.
shouldn't you use an nsCOMPtr?
I think since its a Singleton.. created only once and registered as a service for the life of the App.. it does not need to use a nsCOMPtr. The registration keeps track of this object for the life of the application.
dcone: you've created a leak, because RegisterService adds its own ref to the service-instance you pass in (as it has to, per the rules of XPCOM -- the caller cannot "hand off" its own reference). That leaves the reference added by CreateInstance for its out parameter stuck, which means a leak. It's a new millennium, there really is no excuse not to use nsCOMPtrs. But you still need to know the rules of XPCOM, or you can get burned by cycles and bad ownership models. /be
*** Bug 65952 has been marked as a duplicate of this bug. ***
Can we get a target milestone on this bug please? 0.8 would be good, 0.9 would be acceptible.
Setting milestone for mozilla0.9. For mozilla0.9. We will enable bringing up the native Mac PageSetup dialog.
Target Milestone: --- → mozilla0.9
Summary: Page setup (Print setup) is unimplemented → Mac Page Setup needs to be implemented [mac][print][print ui]
Note: We need this print menu for Mail 3-pane window too. With 4.7x I can access print Landscape with the Page Setup menu item. I can't print Landscape on Mac and Linux with 6.01 or 6.5 because Page Setup is missing (and I haven't found another way to access it). I will put my name on the CC list, if the Mail 3-pane window File menu list is done by mailnews group, please let me know and I'll write a new bug. I did not see that this was specific to mac.
May want to rename ShowNativeDialog to ShowNativePageSetupDialog. Since we may also want to support ShowNativePrintDialog later. firstname.lastname@example.org
it doesn't look like this will work under carbon.
the native call is there for the Mac OS9. I created a new bug 76378 for hooking this up.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Depends on: 76378
Resolution: --- → FIXED
Not sure how I can verify this .. Don, if this is just a code issue let me know..
Chris--I don't really think you can verify this bug until 42817 and 65871 are fixed (since we can't easily know if all of the page setup functionality works without the UI) :-/
Why was this considered fixed? It sure isn't on the Mac.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is fixed.. because the call is there. There are other bugs.. that mention putting page setup in the file menu. This bug was about getting the Mac Pagesetup working with and API. So my part on this issue for the Mac is complete.
Marking fixed. Another bug was opened for using the Mac Print Setup code that was implemented here.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
This is so not working. I see no way that the mPrintRecord stored in nsPrintOptionsMac() ever get to the printing code.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
nsPrintOptionsMac did simply not work, and must never have been tested. Bad things: PrStlDialog() was not called inside a PrOpen/PrClose block, so it rarely worked. And when it did, the watch cursor showed up over it. Also, there was no way the print record we got from PrStlDialog() could be fed into the printing code. This in-progress patch adds a 'GetNativeData' call to nsIPrintOptions, which the mac printing code can use to get at the print record. It also does a bunch of cleanup, so it larger than necessary.
Patch looks fine except there is a little more whitespace cleanup you could do (for example the following line and the line that follows it): sDefaultFont = new nsFont("Times", NS_FONT_STYLE_NORMAL,NS_FONT_VARIANT_NORMAL, and also this line you added: NS_IMETHOD GetNativeData(PRInt16 aDataType, void * *_retval); StHandleOwner seems to have tabs in it nsPrintOptionsMac::~nsPrintOptionsMac() also seems to have tabs in it (though you aren't touching much there right now) r=brade
Assignee: dcone → sfraser
Status: REOPENED → NEW
The last patch adds Page Setup functionality for Mac OS classic and Mac OS X. It stores page setup settings in the preferences (as a Base64-encoded string) between runs, and will load the settings from prefs when nsIPrintOptions is instantiated for the first time (i.e. a page setup in the last session will affect printing in a subsequent session). Because the code that shows the page setup dialog is separate from the printing code, and not in a per-window or per-document data structure, we are not able to use the Carbon session-based printing APIs. We have to use the more backwardly- compatible non-session APIs instead, so I had to touch some of the Mac OS X printing code. Note that you'll need the XUL patch in bug 42817 to see page setup in the UI. Reviews please.
Status: NEW → ASSIGNED
Note that you also have to add nsPrintOptionsX.cpp to the carbon targets of gfx.mcp to have this work.
Yea! Thanks. I'm not too familiar with Carbon printing but the patch looks good. I'll apply it and check it out further.
Note to self: this line: + ::PMDefaultPageFormat(mPageFormat); in nsPrintOptionsX::ShowNativeDialog() needs to be removed.
Comment on attachment 53208 [details] [diff] [review] Review-worthy gfx patch ok, looks decent to me, pending a thorough mac r= :) sr=
Attachment #53208 - Flags: superreview+
sdagley gave an r=
These changes are in, now. No menu item yet, tho (see bug 42817).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
PDT+, let's get this into the 094 branch. cc'ing robinf and msanz.
This has been checked in on the 0.9.4 branch
cc yxia and danielmc and rclose - not sure if there is new UI for this or not.
Verifying that page setup command is functional in the trunk OS 9 build (2001-10-16-08). *Used Page setup dialog to scale print out at 50, 75, 100, 150 % out of composer and navigator. *Specified Landscape and portrait modes and printed page. *Switched between printers in Page setup dialog and printed page.
Chris, when Mac branch builds are out, try these things out per Simon's email: On Mac & Mac OS X: * Verify that Page Setup appears in every File menu that has Print. * Verify that Page Setup appears on Composer's Print toolbar button dropdown (it was there before), but not on any other Print toolbar dropdowns (this is just the way things were, not a deliberate design choice). * Verify that Page Setup works in every location in which it appears (including when no windows are open). It should show the Page Setup dialog for the currently selected printer, and should remember settings from the last time you used it, even if in a previous session (settings are stored in prefs, hence are per-profile). Printing should use the last-specified Page setup options. Switching between printers should not cause problems; test the case of doing Page Setup in printer A, switching to printer B, and then doing a Print without a preceding Page setup. Test when no printer is selected (remove all printers). * Verify that printing on Mac OS X still works as it did before. On Windows & Unix: * Verify that File menus look as they did before this change, that Print still works, and that Page Setup on Composer's toolbar button dropdown does nothing bad.
Verified on the Mac OS X build (2001-10-16-04). * Page setup command appears in all application modules: Nav, IM, Mail, Composer, Address Book * Print button popup in Composer displays Page setup option and is functional. * Page setup dialog shows previous settings * Printed from Composer, Nav, Mail, and IM. Need to still test on Mac OS 9 branch...
Under Windows branch (2001-10-16-05) , Print function works from File menu and Composer's Print button. Sujay, My linux machine has been setup for my network printer so I will need you to check this.
Sorry, my linux machine hasn't been setup to print... Need for you to check..
Chris, I will take care of the linux issue. Mac branch builds are out...you can go ahead and verify this on branch using Simon's verification instructions. thanks.
Verified on the Mac OS 9 branch build (2001-10-17-03) * Page setup appears and works in Nav, IM, ,Mail, Composer , and Address book. * Previous settings appears in page setup dialog. * Printed from Nav, IM, Mail and Composer after specifing various scaling and page settings. * Switching to between different printers is successful and print jobs are sent poroperly.
Marking verified on both Mac OS 9 and OS X 10.1
Status: RESOLVED → VERIFIED
verified on Linux 10/17 branch build the following per Petersens/Simons request: * File menu works and appears they way it did before thix fix * Print functionality works * Page Setup on Composer's toolbar button drop-down does nothing bad
Is this expected? I tried to use scaling and orientation on the Page Setup dlg and then print. Looks great. However, when I view the preferences js file (which I know most users won't do), for the parameter for user_pref("print.macosc.pagesetup"), I get a huge section of characters which seem encrypted to me.
It's not encrypted. It's just a native print record which is base64 encoded as text so it can be put in a prefs file. Same thing as with file aliases in Mac prefs files. I wouldn't worry about it.
What Conrad said. That's expected.
You need to log in before you can comment on or make changes to this bug.