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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Simon Fraser [no longer active]]

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

Comment 1

[dcone (gone)]

This is a chrome issue... not sure who gets this..

Comment 2

[Simon Fraser [no longer active]]

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?

Comment 3

[Simon Fraser [no longer active]]

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.

Comment 4

[dcone (gone)]

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).

Comment 5

[leger]

Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.

Comment 6

[Brendan Eich [:brendan]]

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

[jglick]

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

Comment 8

[don]

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.

Comment 9

[karnaze (gone)]

Triage duty calls. Reassinging to av.

Comment 10

[leger]

On exception list for PR2, removing 5/16...giving [nsbeta2+]Exception Feature 
status.

Comment 11

[leger]

*** Bug 11767 has been marked as a duplicate of this bug. ***

Comment 12

[Kevin McCluskey (gone)]

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?

Comment 13

[Simon Fraser [no longer active]]

That's an excellent analysis, and the bug, as filed, covers all parts. Feel free 
to break them out into separate parts.

Comment 14

[Kevin McCluskey (gone)]

CC'ing Syd

Comment 15

[Kevin McCluskey (gone)]

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

[Phil Peterson]

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-

Comment 17

[dcone (gone)]

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.

Comment 18

[Pierre Saslawsky]

Page Setup not critical? I'll be damned!

Comment 19

[Simon Fraser [no longer active]]

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

[dcone (gone)]

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

Comment 21

[Pierre Saslawsky]

Cool... Changed milestone from Future to M18.

Comment 22

[dcone (gone)]

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.

Comment 23

[Brendan Eich [:brendan]]

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

[Pierre Saslawsky]

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.

Comment 25

[Kevin McCluskey (gone)]

Marking in nsbeta3-

Comment 26

[Daniel Veditz [:dveditz]]

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the 
queries don't get screwed up

Comment 27

[Pierre Saslawsky]

Removing future/beta3- for reconsideration, per jar and michaell at the
"Mac sucks" meeting.

Comment 28

[Jim Roskind]

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

[dcone (gone)]

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. 

Comment 30

[Kevin McCluskey (gone)]

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.

Comment 31

[Kevin McCluskey (gone)]

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

Comment 32

[leger]

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.

Comment 33

[Jason Eager]

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".

Comment 34

[Kevin McCluskey (gone)]

Marking nsbeta3-.

Comment 35

[Loco]

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

[Loco]

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.

Comment 37

[Peter Trudelle]

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

Comment 38

[Kevin McCluskey (gone)]

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

[Paul Wyskoczka]

Adding shrir to the cc list

Comment 40

[Simon Fraser [no longer active]]

I really agree with the above few comments. Clearing status whiteboard for 
reconsideration.

Comment 41

[Simon Fraser [no longer active]]

Adding nsmac2 keyword, since printing is important for Mac, and IE 5 currently 
beats us hands down here.

Comment 42

[Kevin McCluskey (gone)]

Would love to fix this, but there just isn't time before beta3.
Added helpwanted keyword.

Comment 43

[Simon Fraser [no longer active]]

Are we really not going to fix this for rtm? Adding keyword, to get it on radar.

Comment 44

[dcone (gone)]

Attachment: Example patch to implement page setup. See comments below

Comment 45

[dcone (gone)]

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

[Peter Trudelle]

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.

Comment 47

[Kevin McCluskey (gone)]

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.

Comment 48

[Michael La Guardia]

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.

Comment 49

[Mike Pinkerton (not reading bugmail)]

cc'ing folks on the xpapps team

Comment 50

[Blake Ross]

I can probably add this.   We already have a [disabled] Page Setup item, so 
this shouldn't be a problem wrt internationalization.

Comment 51

[Kevin McCluskey (gone)]

Marking rtm-. Getting off the rtm radar.

Comment 52

[[e-mail] (gone - use [e-mail] instead)]

Interesting bug, so I'm cc:ing myself to this.

Comment 53

[Kathleen :Brade]

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.

Comment 54

[Kristi Fredrickson]

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

[dcone (gone)]

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.

Comment 56

[Kathleen :Brade]

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?

Comment 57

[Matthias Versen [:Matti]]

*** Bug 60475 has been marked as a duplicate of this bug. ***

Comment 58

[Matthias Versen [:Matti]]

Page setup is also not available on Windows 2000 and Windows 98
(Trunk build 2000111604)

Comment 59

[verah (gone)]

Removing myself from list of cc's.

Comment 60

[hirata masakazu]

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.

Comment 61

[hirata masakazu]

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

[Blake Ross]

Since we seem to have a prototype ready, nominating for beta1.

Comment 63

[hirata masakazu]

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

[dcone (gone)]

Attachment: Apprunner service starting patch

Comment 65

[dcone (gone)]

Attachment: setregistry patch

Comment 66

[timeless]

shouldn't you use an nsCOMPtr?

Comment 67

[dcone (gone)]

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.

Comment 68

[Brendan Eich [:brendan]]

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

Comment 69

[Doron Rosenberg (IBM)]

*** Bug 65952 has been marked as a duplicate of this bug. ***

Comment 70

[Simon Fraser [no longer active]]

Can we get a target milestone on this bug please? 0.8 would be good, 0.9 would be 
acceptible.

Comment 71

[Kevin McCluskey (gone)]

Setting milestone for mozilla0.9.

For mozilla0.9. We will enable bringing up the native Mac PageSetup dialog. 

Comment 72

[esther]

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

[dcone (gone)]

Attachment: A small patch to complete the job

Comment 74

[Kevin McCluskey (gone)]

May want to rename ShowNativeDialog to ShowNativePageSetupDialog. Since we may 
also want to support ShowNativePrintDialog later.

r=[e-mail]

Comment 75

[Marc Attinasi]

sr=attinasi

Comment 76

[Mike Pinkerton (not reading bugmail)]

it doesn't look like this will work under carbon.

Comment 77

[dcone (gone)]

the native call is there for the Mac OS9.
I created a new bug 76378 for hooking this up.

Comment 78

[Chris Petersen]

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

Comment 79

[Kathleen :Brade]

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)  :-/

Comment 80

[Conrad Carlen (not reading bugmail)]

Why was this considered fixed? It sure isn't on the Mac.

Comment 81

[dcone (gone)]

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

[dcone (gone)]

Marking fixed.  Another bug was opened for using the Mac Print Setup code that 
was implemented here.

Comment 83

[Simon Fraser [no longer active]]

This is so not working. I see no way that the mPrintRecord stored in 
nsPrintOptionsMac() ever get to the printing code.

Comment 84

[Simon Fraser [no longer active]]

Attachment: Make nsPrintOptionsMac do something

Comment 85

[Simon Fraser [no longer active]]

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.

Comment 86

[Kathleen :Brade]

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

Comment 87

[Simon Fraser [no longer active]]

Attachment: Better patch for gfx

Comment 88

[Simon Fraser [no longer active]]

Mine

Comment 89

[Simon Fraser [no longer active]]

Attachment: Review-worthy gfx patch

Comment 90

[Simon Fraser [no longer active]]

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.

Comment 91

[Simon Fraser [no longer active]]

Note that you also have to add nsPrintOptionsX.cpp to the carbon targets of 
gfx.mcp to have this work.

Comment 92

[Conrad Carlen (not reading bugmail)]

Yea! Thanks. I'm not too familiar with Carbon printing but the patch looks good.
I'll apply it and check it out further.

Comment 93

[Simon Fraser [no longer active]]

Note to self: this line:

+  ::PMDefaultPageFormat(mPageFormat);

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

Comment 94

[Alec Flett]

Comment on attachment 53208 [details] [diff] [review]
Review-worthy gfx patch

ok, looks decent to me, pending a thorough mac r= :)
sr=

Comment 95

[Simon Fraser [no longer active]]

sdagley gave an r=

Comment 96

[Simon Fraser [no longer active]]

These changes are in, now. No menu item yet, tho (see bug 42817).

Comment 97

[Jaime Rodriguez, Jr.]

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

cc'ing robinf and msanz.

Comment 98

[Simon Fraser [no longer active]]

This has been checked in on the 0.9.4 branch

Comment 99

[Michele Carlson]

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

Comment 100

[Chris Petersen]

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.

Comment 101

[sujay]

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

[Chris Petersen]

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

[Chris Petersen]

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

[Chris Petersen]

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

Comment 105

[sujay]

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

[Chris Petersen]

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

[Chris Petersen]

Marking verified on both Mac OS 9 and OS X 10.1

Comment 108

[sujay]

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

[lchiang]

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. 

Comment 110

[Conrad Carlen (not reading bugmail)]

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.

Comment 111

[Simon Fraser [no longer active]]

What Conrad said. That's expected.