42817 - Page setup (Print setup) XP dialog needs to be implemented

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Kevin McCluskey (gone)]

This bug was broken off from bug 36796 which covers the printer API's and 
bringing up printer driver specific dialogs.

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.

This bug covers the cross-platform page setup dialog. The API's that this dialog 
will call to setup printing is covered in bug 36796.

This bug also covers the setting and getting of the values for the 
cross-platform dialog from the user prefs.

Comment 1

[Kevin McCluskey (gone)]

Marking as [nsbeta2+]Exception Feature since this bug was broken out of an 
existing bug which was already marked [nsbeta2+]Exception Feature

Comment 2

[Asa Dotzler [:asa]]

not sure if this is a toolkit issue or an XPApps issue, but it's probably not a
Browser General issue (if people are actually supposed to see it, that is) .
goint to XP Apps first.

Comment 3

[Henri Sivonen (:hsivonen)]

>page setup dialog where the user specifies margins, whether or 
>not to print the background etc.

I don't think those settings belong to Page Setup in an app like Mozilla.

Ideally, these setting should go in a Print As... dialog (aka. Print Preview). Until there is 
such a dialog, the Print dialog is a better place for settings that may get changed 
depending on a particular page. The user shouldn't need to open the Page Setup dialog 
to choose whether to print the background, close the dialog and then open the Print 
dialog.

Comment 4

[Simon Fraser [no longer active]]

I agree with Henri there. In other mac applictions, per-print options like 
margins, background etc should go into a panel of the print dialog (and APIs 
exist to extend the print dialog for this very reason). Otherwise, the user has 
to go through a series of two dialogs to print, which is bad.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

these bugs need to go through don first. I already have a full plate for 
nsbeta2. sorry. 

Comment 6

[Kevin McCluskey (gone)]

In WIN32 apps the page setup dialog usually contains the margin settings.

We need to have a single cross-platform page setup dialog which has the same 
controls regardless of the platform it is running on. Inserting some of the page 
setup controls onto the print dialog can not be done in an XP way. 

Comment 7

[Kevin McCluskey (gone)]

Ok, disregard my last comment. I talked to dcone and I think we have a design 
which will make you happy. We will make a nsIPrintSetup interface that is 
responsible for getting and setting the print data + bringing up the page setup 
dialog. the nsIPrintSetup interface can be implemented natively for the Mac and 
it will be totally up to the platform specific Mac implementation to decide what 
goes on the page setup dialog and what goes on the print dialog. For win32 and 
Linux the nsIPrintSetup  will require a ShowPage Listener be registered to bring 
up a XUL-based page setup dialog. 

something like:

class nsIPrintSetup {
  GetMargins(PRInt32 left, PRInt32 right,PRInt32 top,PRInt32 bottom);
  SetMargins(PRInt32 left, PRInt32 right,PRInt32 top,PRInt32 bottom);

  GetPrintBackground(PRBool& aPrintBackground);
  SetPrintBackground(PRBool aPrintBackground);

  ...


   // On WIN32 and Linux all this method does is ask the aListerner to show the
   // page setup dialog. 

   // It is up to the browser to register an aListerner
   // and bring up a XUL-based page-setup dialog when the aListener is asked
   // to showdialog. the XUL-based page-setup will be modal. When it    //    // 
returns after the user hits OK it
   // must call the nsIPrintSetup's Set methods.
  ShowPageSetupDialog();
  

  // This method will be called in the Browser code to register the
  // nsIPageSetupListener 
  SetShowPageSetupDialogListener(nsIPageSetupListener aListener)
}

class nsIPageSetupListener {
  ShowPage();
}

The browser code will also be responsible for reading and setting the printer 
prefs by calling nsIPrintSetup

Comment 8

[Henri Sivonen (:hsivonen)]

Ideally the File menu should have two printing-related items (as in the Aphrodite menu 
spec):
Print… (or Print One Copy)
Print As...

Print... would print the page with whatever default settings.
Print As... would bring up a preview window with all the relevant margin and font size 
settings. That window would have a button for proceeding to the platform-specific Print 
dialog.

The user would almost never need to access Page Setup. For the rare cases there would 
be a button in the Print As... window for opening the platform-specific Page Setup dialog.

There would be no need to extend the platform-specific dialogs.

Comment 9

[don]

Why was the whiteboard status of this bug "[nsbeta2+]Exception Feature"?  This
feature was killed for beta 2?  Clearing whiteboard status for re-consideration.

Comment 10

[sairuh (rarely reading bugmail)]

over to Printing component.

Comment 11

[Michael La Guardia]

marking nsbeta2- per don's comments.

Comment 12

[german]

Sorry for butting in with my comment but from I can tell I don't even think it is 
good user experience to have *two* cascading dialogs for the printer setup. This 
end user will not care for the fact what we can do in XUL vs in native dialogs. 
If localization is the only reason, I don;t think we should subject users to this 
annoying workaround.
Considering the resources and time we have throwing up the native page setup 
dialogs seems to the lesser evil here.

Comment 13

[Kevin McCluskey (gone)]

The only platform that has a native PageSetup dialog is Mac. WIN32 and Linux do 
not have native dialogs for PageSetup. If someone wants the invest the time to 
add the additional controls to the native PageSetup dialog on the Mac thats fine 
with me, but we still need a solution on WIN32 and Linux. The application 
usually defines all of the settings that are present on the PageSetup dialog. 
Mac has some of the settings that are usually on the native Print dialog on the 
PageSetup dialog which is why you always need to be able to bring up the native 
PageSetup dialog on the Mac.

Comment 14

[Henri Sivonen (:hsivonen)]

>but from I can tell I don't even think it is good user experience to have *two* 
>cascading dialogs

Do you mean the Print As... scenario? The first one would be more like a preview mode 
than a regular dialog. The UE could be made very good. With a good preview 
implementation, you don't want to print without it again.

Comment 15

[Chris McAfee]

mcafee, m18

Comment 16

[johng]

nav triage team:

nsbeta3+
reassigned to johng to determine what minimum spec should be.  cc'ing sol to get
input.

Comment 17

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 18

[Blake Ross]

this nsbeta3+ has remained dormant for a month and a half, not even assigned to 
an engineer.  reassigning to kevin to figure out what to do with this.

Comment 19

[Kevin McCluskey (gone)]

marking nsbeta3-. This is an exception feature that declared to be out by PDT a 
while back. 

Comment 20

[Chris McAfee]

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

Comment 21

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 22

[Kevin McCluskey (gone)]

The backend work is covered by bug 36796. Reassigning this bug to vishy for the
front-end XUL/UI work.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Kevin McCluskey (gone)]

bug 36796 has been closed. It covers the backend work to bring up the Mac Native
PageSetup dialog.

We should add the PageSetup menu item for Mac and bring up the Native Mac Dialog
(This would allow Mac user's to specify landscape/portrait for the printer
output, etc.)

Comment 25

[hirata masakazu]

since 0.9.1 has branched, and there are only 0.9.2 and 0.9.3 planned before 1.0,
this can not be left nsbeta2 or nsbeta3, right?
nominating for 0.9.2.

Comment 26

[timeless]

dcone/german: is there a spec for this? if not would someone please work on 
proposing a spec (perhaps in newsgroups and then as a bug in bugzilla)?

Comment 27

[Viswanath Ramachandran]

nav triage: vishy wont do this in mozilla0.9.2. 

Comment 28

[hirata masakazu]

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

Comment 29

[Bob Jacobson]

I appreciate the desire for parsimony, but without the Print Setup feature, Mac
printing is effectively only half under the user's control.  If Mac users have
to invoke Netscape 4.77 everytime they need to print a webpage, what advantage
is that to using a more contemporary version like Mozilla?

Comment 30

[hirata masakazu]

nominating for  0.9.3

Comment 31

[Bill McGonigle (not currently reading bugmail; please contact directly)]

fizzilla needs Page Setup too.

Comment 32

[Mastropos]

Is anybody still on this one?
0.9.3 passed long ago...

With the current situation, I always have to open NS4\IE to print a page with no
headers\footers, reduced margins etc...

Comment 33

[Benjamin Mucci]

Why milestone is set to future? Not really serious for Macuser...

Comment 34

[hirata masakazu]

nominating for 0.9.5
This certainly needs to be implemented before Mozilla can claim itself an
official release.

Comment 35

[Kathleen :Brade]

remove milestone and reassign

Comment 36

[Kevin McCluskey (gone)]

Bill, I think this is probably a dup of a bug you already have. This bug covers
the UI and glue code necessary to implement the page setup dialog. All of the
backend work is complete see bug 36796.

Reassigning to [e-mail]

Comment 37

[Bill Law]

Setting target milestone; I'll coalesce with the other (dup) bug when I run 
across it.

Comment 38

[Simon Fraser [no longer active]]

Attachment: Show Page Setup menu item in File menu for browser

Comment 39

[Simon Fraser [no longer active]]

Just added a dumb patch that shows the Page Setup menu item on all platforms. The 
JS just gets the nsIPrintOptions service, and calls ShowNativeDialog() which only 
does anything on Mac). We probably need some platform overlay magic here. Note 
that to get mac to do anything useful, you'll need the patch in bug 36796.

Comment 40

[Kathleen :Brade]

Comment on attachment 53040 [details] [diff] [review]
Show Page Setup menu item in File menu for browser

r=brade

Comment 41

[Bill Law]

Paul is going to be dealing with printing stuff.

Comment 42

[Simon Fraser [no longer active]]

There is a mail bug 65871 which may be a dup of this.

Comment 43

[Simon Fraser [no longer active]]

Is there really a plan to show an XP (read: XUL) dialog at some stage in the 
printing process? If so, this raises may issues:
1. Is it shown in response to Page Setup, or Print?
2. How does it gel with the native page setup and print dialogs? You *have* to 
show the native dialogs, because only they can allow access to features which are 
specific to the print driver that the user has. And popping up native dialogs 
before/after XUL dialogs will look like crap.

I propose that for Page Setup and Print, we only use native dialogs. We should 
allow the user to specify mozilla-specifci printing options using a Preferencea 
panel, or separate 'Printing options' dialog that is available on a different 
menu item.

Comment 44

[Benjamin Mucci]

In my mind the current implantation in Internet Explorer under MacOS is the best
one.
With LW 8.6.x:
-----------------
| File          |
-----------------
[...]
- Pages Setup
- Print Preview       (IE options Header/Footer/Background... at the bottom)
- Print ...           Drop down Menu: Internet Explorer > Same option as in
Print preview but w/o the preview
[...]

-----------------

My 2 cents.

Comment 45

[Simon Fraser [no longer active]]

The page setup backend support in bug 36796 is ready for review. Let's get the UI 
sorted out soon so nothing is held up.

Comment 46

[Simon Fraser [no longer active]]

Attachment: Fix Page setup for mailnews windows

Comment 47

[Simon Fraser [no longer active]]

Attachment: Fix page setup for navigator

Comment 48

[Simon Fraser [no longer active]]

Attachment: Fix page setup for editor

Comment 49

[Simon Fraser [no longer active]]

The last 3 patches enable Page Setup, which gets overlayed for Mac only, to work 
in Editor, Navigator, and Mailnews (including 3-pane, message window, and addr 
book).

Comment 50

[Simon Fraser [no longer active]]

Changes for AIM are in bugscape bug 10451.

Comment 51

[Simon Fraser [no longer active]]

Reviews please:
  cmanske/brade (editor), pchen (navigator), hwaara (mailnews)
  sr from blake, if you would be so kind.

Comment 52

[(not reading, please use [e-mail] instead)]

Comment on attachment 53385 [details] [diff] [review]
Fix Page setup for mailnews windows

r/sr=sspitzer

Comment 53

[Håkan Waara]

Comment on attachment 53385 [details] [diff] [review]
Fix Page setup for mailnews windows

mail code looks fine to me.

r=hwaara

Comment 54

[jag (Peter Annema)]

Comment on attachment 53386 [details] [diff] [review]
Fix page setup for navigator

>Index: communicator/resources/content/utilityOverlay.js
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/communicator/resources/content/utilityOverlay.js,v
>retrieving revision 1.46
>diff -b -u -2 -r1.46 utilityOverlay.js
>--- utilityOverlay.js	2001/09/28 20:13:32	1.46
>+++ utilityOverlay.js	2001/10/13 01:23:42
>@@ -128,4 +128,14 @@
> function goPageSetup()
> {
>+  // This code brings up the native page setup dialog (for platforms that
>+  // implement nsIPrintOptions.ShowNativeDialog()).  
>+  var printOptionsService = Components.classes["@mozilla.org/gfx/printoptions;1"]
>+                                           .getService(Components.interfaces.nsIPrintOptions);
>+  if (!printOptionsService)
>+    throw Components.results.NS_ERROR_FAILURE;

If getService() fails, an exception will automatically be thrown, so if you reach
the line after getService(), you can assume it to have worked.

If this is a service that may not always be present, check for it like this:

const PRINTOPTIONS_CONTRACTID = "@mozilla.org/gfx/printoptions;1";
if (!(PRINTOPTIONS_CONTRACTID in Components.classes))
  return;

var printOptionsService = ...

>+
>+  printOptionsService.ReadPrefs();
>+  printOptionsService.ShowNativeDialog();
>+  printOptionsService.WritePrefs();
> }
> 
>Index: global/resources/content/mac/platformGlobalOverlay.xul
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/global/resources/content/mac/platformGlobalOverlay.xul,v
>retrieving revision 1.15
>diff -b -u -2 -r1.15 platformGlobalOverlay.xul
>--- platformGlobalOverlay.xul	2001/04/05 19:53:09	1.15
>+++ platformGlobalOverlay.xul	2001/10/13 01:23:51
>@@ -15,4 +14,7 @@
>   <!-- quit -->
>   <menupopup id="menu_FilePopup">
>+    <!-- Page setup -->
>+    <menuitem id="printSetupMenuItem" insertbefore="printMenuItem"
>+          label="&printSetupCmd.label;" accesskey="&printSetupCmd.accesskey;" command="cmd_printSetup"/>

The most common style is to align attributes on the second, third, etc. lines with
the first attribute on the first line.

r=jag if you make the suggested changes as appropriate.

Comment 55

[jag (Peter Annema)]

Comment on attachment 53387 [details] [diff] [review]
Fix page setup for editor

r=jag

Comment 56

[Blake Ross]

sr=blake on all of them with jag's comments.  Too tired to update all 3 and
don't want to spam.

Comment 57

[Simon Fraser [no longer active]]

Those change are in (so I obsoleted teh patches). This bug stays open for the XP 
print setup dialog, however that turns out.

Comment 58

[Simon Fraser [no longer active]]

These changes have been checked in on the 0.9.4 branch.

Comment 59

[Kevin McCluskey (gone)]

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

Comment 60

[Roland Mainz]

Is this a DUPLICATE of bug 84947 ("We need a "better" print dialog..." - we have
a ready-to-go patch there which is currently in the review queue...) ?

Comment 61

[Paul Chen]

moving to mozilla0.9.8

Comment 62

[Peter Trudelle]

->law

Comment 63

[Bill Law]

Implemented as part of the patch for bug 113197.

Comment 64

[Olga]

It seems that re-opening this one and bug 65871 is fair, since Mac shows now
this menu item, but the dialog needs more work. I've just try it and got first
Alert warning in both cases of selected message or focused Message pane.  The
text on this "Alert" (instead of meaningful title) states: "Printsetting arg is
null!", which is usefull for developer, but not for a user. 
1.  Code warning instead of user friendly regular warning for Print Setup
warning message.  BTW, when to expect it? 
2. After closing that Alert, Print Setup dialog appears without title bar. 
There is focus on OK but pressing Enter does not activate it.  Pressing on ESC
does not activate Cancel. I realize it is new, I don't list other UI issues.
 

Comment 65

[Bill Law]

Olga, re-opening this might be "fair" but I'd rather not, please?

The Mac problems with the XP dialog are covered by bug 118889.

This bug summary says "...XP dialog needs to be implemented."  It is.  There 
are other more focused bugs to track remaining issues.  There is litle 
discussion here that's pertinent to those issues, so moving on is best, I think.

The problem is that leaving this bug open till the XP Page Setup dialog is 
perfect means that it will *never* get closed.

Comment 66

[sujay]

verified.