This is a suggestion. Maybe the UE people should decide this. OS X apps have built-in print preview using the Preview button in the print dialog. Given that this works for us, the Print Preview mode is somewhat redundant on OS X. (The only apps that have a Print Preview menu item in OS X are apps that migrated from OS 9 AFAICT.)

Over to the UI folks

CC'ing some folks since we need a decision here. Our print preview UI gives the user the ability to view a scaled document and to change the orientation while in print preview whereas the native Mac OS X one doesn't. Would Mac OS X users prefer consistency over loss of this functionality? Is this functionality trivial given that we now have the ``Shrink to fit page width'' option in the page setup dialog (which will be exposed in the print preview toolbar as well)? My vote would be to leave this functionality in until Mac OS X started including it with the native print preview.

an idea mentioned before - could we have our print preview menu item take the user to the standard OSX print preview? If not then i agree with Dave that it would be redundant to provide the same functionality, all things being equal. Are we sure that OSX print preview does a good job print previewing web content, unweildy web pages? I have not played with it yet myself.

cc dcone, who's working on print dialog extensions for Mac os X

marlon: OS X's print preview simply prints the page to a .pdf file, that is then displayed using the Preview app. It shows the document exactly as it will be printed, but has no UI of its own to control layout.

as long as it provided the venerable fit-to-page, we would be ok. i will go investigate it right now...

it does a nice job with IE output, but i think it's IE that's doing the work. Because if i load one of my unweildy specs into mozilla, Apple's print preview chops off the right side with no way to fit-to-page. Maybe that's been corrected since we've defaulted fit-to-page to on. If it has then i think we would be fine with removing the menu item.

Somehow I've managed to get Acrobat Reader to show my print previews instead of the Preview application.

I like the scaling tool in Mozilla. The built-in OS X Preview command does not offer this functionality, which is very useful in a web browser. But I prefer the scaling in MSIE, even though it's dog slow, becuase MSIE's preview WORKS. The actual printed output from Mozilla RARELY matches the print preview. Is there an open bug for this somewhere?

What part doesn't work? All the line breaking is accurate and the number of pages matches. It just the font size in PP isn't always scaled correctly (which is something we are working on) so sometimes it looks like it is getting cropped when it isn't. Please comment specifically on what doesn't work (where PP doesn't match Printing) so it can be fixed.

i agree with hyatt (comment 0), and i'd like to do the same thing for BeOS for a similar reason. BeOS has a print preview printer, and people are supposed to use it.

The scaling/orientation tools should probably be in a custom printing dialog extension. Then the Print Preview menu item can go away, but users can still have control over what is shown in Preview.app. docs: http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Printing/ExtPrintingDialogs/PDEConcepts/Functional_Components.html

Hmm, in Jag, pressing "Preview" brings up a save dialog. That doesn't seem right.

Bill, I just tested Print Preview on Jaguar OS and it does not bring up the Save dialog. What build are you using ?

OK, this is strange. Not sure whose fault it is, but try this to reproduce it: File...Print... Choose 'Output Options' from pop-up menu. Check 'save as file'. Click 'Preview'. But wait, it gets even more weird. When I uncheck the save to file, and click 'Preview' (it comes up OK then), the document title is the name of a webpage I looked at sometime yesterday. I think I also printed it to a PDF, but that was on a different disk. I'll attach a screenshot to show what I mean.

under Jag 6C115. Note: I quit Preview.app and clicked 'Preview' several times, same result each time.

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

nominating.

See bug 188508. That was checked into Chimera already and allows control over Shrink To Fit (though, internally the impl is broken on all platforms last I checked) and applies to Print Preview. Another advantage of the OS-standard Print Preview: The imaging model for printing on OSX is PDF, and the standard PP is the actual print spool file, just rendered to the screen. Because of this, it's absolutely dead-on WYSIWYG - including the margins. Our own PP is horribly inaccuate WRT margins.

Perhaps it's just me, but Mozilla's Print Preview is totally unhelpful. The scaling and landscape buttons do nothing, and the preview is almost always wrong. See bug 188207 for an example. So as it stands currently, eliminating the Print Preview menu item would be great. Even better, however, would be a fully adjustable preview equivalent to MSIE 5 for Mac. But that's an RFE for another day.

Nav triage team: nsbeta1-

why would this be difficult to remove for OS X?

-> conrad per navtriage email.

Note, if we don't fix this for the browser & Mail then we need to fix bug 181552 for the Blank window you get clicking on the Print Preview menu item within Mail. I will nominate 181552 again. Please fix one of them.

> I will nominate 181552 again. Don't do that. This is the one we need. (1) The Print PDE is landed on the trunk now (2) The XUL Print Preview has layout inaccuracies in addition to its other problems.

We should get this for the planned long-lived 1.4 branch. Who can help?

I have a patch which moves the PP menu item out into platform overlays for unix & win, not mac. Now, for the toolbar menu...

ccarlen: can you make it possible for BeOS not to have the menu either?

The toolbar wasn't a problem. Mail and Address Book will be. The PP menu item appears in 3 places there, and none have platform overlays.

Moves the PP menu item out into platform overlays. Takes care of navigator File menu and toolbar popup.

Gets rid of it from File menu and context menus. For some reason, the top-level jar.mn in mailnews was just hardcoded to use the Windows platform overlay, though the others existed (sort of - various jar.mn files and a Makefile were missing, so I had to create those)

The two patches get rid of it everywhere except address book. I mistakenly thought this had gotten 1.4b+, so I went this far. Now that I see it's not, I don't have the time to do the address book part. But, at least having it removed from the browser and mail is an improvment, so it might be worth checking in what's here.

cc Seth for mailnews part.

Can we get reviews on this and get it in? As far as I can tell, we're not dropping any real functionality since the shrink to fit (and any of the sizing items) and the portrait/landscape buttons don't work at all in the latest Mozilla OS X builds

adt: nsbeta1+/adt2

robin, will online help need to be modified for this change? i'll double check the help docs, but was wondering if you might know offhand.

There is Print Preview help, and there are MacOS references. Attaching a suggested modification.

Yes, some small modification of online help would be necessary, as suggested in comment 37 (approx. 25 words of new/changed text). Bobj needs to approve any updates to help.

Comment on attachment 122117 [details] [diff] [review] for navigator Wouldn't a smaller patch be to keep the menuitems where they are and just hide it from the mac platform overlay?

> Wouldn't a smaller patch be to keep the menuitems where they are... Smaller patch, yes. But, why create the item only to hide it, instead of creating it only where it's actually needed?

jag, you suggest something like in the mac overlay: <menuitem id="printPreview" hidden="true"/> I'm worried we might run into some weirdness, with the mac menu code, where the menu is built before we've overlaid the hidden attribute.

well, we hide menu items in the onload hander of the stand alone msg window, so that works. I've just never done it using overlays, but it should work. not sure what I'm worried about.

Yeah, that's what I'm suggesting. I don't think we actually start creating these objects until we're done overlaying, specifically to avoid doing more work than necessary. Conrad: The reason for this approach is less duplication / maintenance.

taking from ccarlen, but it might go to jag or shuehan (or me), depending on who gets done with their other bugs first. discussed it with conrad (and jag), and the goal will be to fix it the way jag suggests.

I like the Mozilla Preview, though it could get even better, providing a "two pages per sheet" option or individual line breaks to get more text on the page. One of the main nuisances in printing web pages is that too much white space is wasted when printing long pages of text formatted in narrow tables.

I would also like to see this fixed in BeOS

accepting, fix (nearly) in hand. looks like it will be a simple, two liner.

fixed. this has r/sr=bienvenu a=sspitzer (it's a 1.4 blocker)

Comment on attachment 125196 [details] [diff] [review] patch r/sr=bienvenu, a=sspitzer

vrfy'd with 2003.06.09.05-1.4 (branch comm) and 2003.06.09.08 (trunk comm) on os x 10.2.6.

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

Removing blocker bug 228000 as it's a Firefox bug and bug 241066 as it's a MailNews bug and certainly didn't block this bug as it was fixed last summer.