Mac Page Setup needs to be implemented [mac][print][print ui]

VERIFIED FIXED in mozilla0.9

Status

()

Core
Layout
P3
critical
VERIFIED FIXED
18 years ago
4 years ago

People

(Reporter: Simon Fraser, Assigned: Simon Fraser)

Tracking

({helpwanted})

Trunk
mozilla0.9
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(1 attachment, 6 obsolete attachments)

(Assignee)

Description

18 years ago
We need to implmement page setup/print setup, store the users preferred printer 
settings etc.

Comment 1

18 years ago
This is a chrome issue... not sure who gets this..
Assignee: dcone → sfraser
(Assignee)

Comment 2

18 years ago
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)

Comment 3

18 years ago
Don: I'm sorry, but I don't see the APIs I can call for this anywhere. Print() is 
a method on nsIContentViewerFile, but there is no corresponding PrintSetup 
method. The only things I can see are in gfx/ps, which is way to low to call from 
JavaScript.
Assignee: sfraser → dcone

Comment 4

18 years ago
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

Updated

18 years ago
Keywords: nsbeta2
Whiteboard: [FEATURE]
Target Milestone: --- → M17

Comment 5

18 years ago
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

Comment 7

18 years ago
See Bug#17608.  The correct term is "Page Setup".

Comment 8

18 years ago
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 → ---

Comment 9

18 years ago
Triage duty calls. Reassinging to av.
Assignee: clayton → av

Comment 10

18 years ago
On exception list for PR2, removing 5/16...giving [nsbeta2+]Exception Feature 
status.
Whiteboard: [nsbeta2+][5/16][FEATURE] → [nsbeta2+]Exception Feature

Comment 11

18 years ago
*** 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
(Assignee)

Comment 13

18 years ago
That's an excellent analysis, and the bug, as filed, covers all parts. Feel free 
to break them out into separate parts.
CC'ing Syd
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.

Comment 16

18 years ago
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

Comment 17

18 years ago
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

Comment 18

18 years ago
Page Setup not critical? I'll be damned!
Keywords: nsbeta2 → nsbeta3
(Assignee)

Comment 19

18 years ago
I hereby attach my concern. Every Mac application that prints has Page Setup. 
Mozilla prints. Therefore, Mozilla must have a Page Setup menu.

Comment 20

18 years ago
I have all the code ready to implement this.. when and if this changes. 
I agree with Simon and Pierre.. 

Comment 21

18 years ago
Cool... Changed milestone from Future to M18.
Target Milestone: Future → M18

Updated

18 years ago
Blocks: 41970

Comment 22

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

Comment 24

18 years ago
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
Keywords: nsbeta2

Comment 27

18 years ago
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

Comment 28

18 years ago
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

Comment 29

18 years ago
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

Comment 32

18 years ago
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

Comment 33

18 years ago
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".
Keywords: 4xp
Marking nsbeta3-.
Whiteboard: [nsbeta3+][nsbeta2-]Exception Feature → [nsbeta3-][nsbeta2-]Exception Feature

Comment 35

18 years ago
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>

Comment 36

18 years ago
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

Comment 37

18 years ago
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
Peter: Don was close to being able to bringing up the Mac native page setup 
dialog, but there's more work to be done and Don is overloaded with other bugs. 
If someone wants to pickup where he left off, that would be great.

Don, correct me if I'm wrong but his is my take on the current state of this 
feature:

Most of the infrastructure is in place to be able to bring up the Native 
PageSetup dialog on the Mac. The print service is checked in and includes a 
method to bring up the NativeDialog. The print service's interface has been 
specified in IDL so it should be accessable to JavaScript.

What remains to be done:
1. Create a Mac specific print service which implements the call to bring up the 
NativeDialog.
2. Use the settings provided by the Mac specific page setup dialog when 
printing.
3. Register the printer service
4. Write the XUL/JavaScript to access the printservice and call the method to 
bring up the Mac page setup dialog.


Comment 39

18 years ago
Adding shrir to the cc list
(Assignee)

Comment 40

18 years ago
I really agree with the above few comments. Clearing status whiteboard for 
reconsideration.
Whiteboard: [nsbeta3-][nsbeta2-]Exception Feature
(Assignee)

Comment 41

18 years ago
Adding nsmac2 keyword, since printing is important for Mac, and IE 5 currently 
beats us hands down here.
Keywords: nsmac2
Would love to fix this, but there just isn't time before beta3.
Added helpwanted keyword.
Keywords: helpwanted
Whiteboard: [nsbeta3-]
(Assignee)

Comment 43

18 years ago
Are we really not going to fix this for rtm? Adding keyword, to get it on radar.
Keywords: rtm

Comment 44

18 years ago
Created attachment 16871 [details] [diff] [review]
Example patch to implement page setup.  See comments below

Comment 45

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

Comment 46

18 years ago
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.
marking [rtm need info]

Still need to add a menu item + Javascript to call the print service method 
which brings up the Native Mac Dialog. Need help from UI/XUL person.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]

Comment 48

18 years ago
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

Comment 50

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

Comment 53

18 years ago
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-]

Comment 54

18 years ago
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?

Comment 55

18 years ago
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

Comment 56

18 years ago
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)

Comment 59

18 years ago
Removing myself from list of cc's.

Comment 60

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

Updated

17 years ago
Target Milestone: M18 → ---

Comment 61

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

Comment 62

17 years ago
Since we seem to have a prototype ready, nominating for beta1.
Keywords: dogfood, rtm → mozilla0.8, nsbeta1
Hardware: Macintosh → All
Whiteboard: [rtm-]

Comment 63

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

Comment 64

17 years ago
Created attachment 22275 [details] [diff] [review]
Apprunner service starting patch

Comment 65

17 years ago
Created attachment 22276 [details] [diff] [review]
setregistry patch

Comment 66

17 years ago
shouldn't you use an nsCOMPtr?

Comment 67

17 years ago
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. ***
(Assignee)

Comment 70

17 years ago
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

Updated

17 years ago
Blocks: 42817

Updated

17 years ago
Summary: Page setup (Print setup) is unimplemented → Mac Page Setup needs to be implemented [mac][print][print ui]

Updated

17 years ago
Keywords: mozilla0.8.1

Updated

17 years ago
Keywords: mozilla0.8

Updated

17 years ago
Blocks: 65871

Comment 72

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

Comment 73

17 years ago
Created attachment 30639 [details] [diff] [review]
A small patch to complete the job
May want to rename ShowNativeDialog to ShowNativePageSetupDialog. Since we may 
also want to support ShowNativePrintDialog later.

r=kmcclusk@netscape.com

Comment 75

17 years ago
sr=attinasi
it doesn't look like this will work under carbon.

Comment 77

17 years ago
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

Comment 78

17 years ago
Not sure how I can verify this .. Don, if this is just a code issue let me know..

Comment 79

17 years ago
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 → ---

Comment 81

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

Comment 82

17 years ago
Marking fixed.  Another bug was opened for using the Mac Print Setup code that 
was implemented here.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 83

17 years ago
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 → ---
(Assignee)

Updated

17 years ago
Attachment #16871 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #22275 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #22276 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #30639 - Attachment is obsolete: true
(Assignee)

Comment 84

17 years ago
Created attachment 53039 [details] [diff] [review]
Make nsPrintOptionsMac do something
(Assignee)

Comment 85

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

Updated

17 years ago
Blocks: 104166

Comment 86

17 years ago
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)

Updated

17 years ago
Attachment #53039 - Attachment is obsolete: true
(Assignee)

Comment 87

17 years ago
Created attachment 53151 [details] [diff] [review]
Better patch for gfx
(Assignee)

Comment 88

17 years ago
Mine
Assignee: dcone → sfraser
Status: REOPENED → NEW
(Assignee)

Updated

17 years ago
Attachment #53151 - Attachment is obsolete: true
(Assignee)

Comment 89

17 years ago
Created attachment 53208 [details] [diff] [review]
Review-worthy gfx patch
(Assignee)

Comment 90

17 years ago
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
(Assignee)

Comment 91

17 years ago
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.
(Assignee)

Comment 93

17 years ago
Note to self: this line:

+  ::PMDefaultPageFormat(mPageFormat);

in nsPrintOptionsX::ShowNativeDialog() needs to be removed.

Comment 94

17 years ago
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+
(Assignee)

Comment 95

17 years ago
sdagley gave an r=
(Assignee)

Comment 96

17 years ago
These changes are in, now. No menu item yet, tho (see bug 42817).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 97

17 years ago
PDT+, let's get this into the 094 branch.

cc'ing robinf and msanz.

Updated

17 years ago
Whiteboard: [PDT+]
(Assignee)

Comment 98

17 years ago
This has been checked in on the 0.9.4 branch

Comment 99

17 years ago
cc yxia and danielmc and rclose - not sure if there is new UI for this or not. 

Comment 100

17 years ago
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.
Keywords: vbranch

Comment 101

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

Comment 102

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

Comment 103

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

Comment 104

17 years ago
Sorry, my linux machine hasn't been setup to print... Need for you to check..

Comment 105

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

Comment 106

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

Comment 107

17 years ago
Marking verified on both Mac OS 9 and OS X 10.1
Status: RESOLVED → VERIFIED

Comment 108

17 years ago
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

Comment 109

17 years ago
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.
(Assignee)

Comment 111

17 years ago
What Conrad said. That's expected.
You need to log in before you can comment on or make changes to this bug.