Closed Bug 129398 Opened 23 years ago Closed 21 years ago

Remove the Print Preview menu item under OS X

Categories

(Core :: Print Preview, defect)

Product:
Core
Component:
Print Preview
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: hyatt, Assigned: sspitzer)

References

(Blocks 1 open bug)

Details

(Keywords: platform-parity, Whiteboard: [adt2][fixed on trunk and branch])

Attachments

(4 files, 1 obsolete file)

wrong title on print preview
201.88 KB, image/jpeg
Details
for mail
14.42 KB, patch
Details | Diff | Splinter Review
Suggested help text
2.00 KB, text/html
Details
patch
3.14 KB, patch
sspitzer
: review+
sspitzer
: superreview+
sspitzer
: approval1.4+
Details | Diff | Splinter Review 
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
Assignee: rods → sgehani
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.
Target Milestone: --- → mozilla1.2
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
Keywords: helpwanted
Target Milestone: mozilla1.2alpha → Future
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.
Keywords: helpwanted → nsbeta1, pp
Target Milestone: Future → ---
  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-
Keywords: nsbeta1 → nsbeta1-
why would this be difficult to remove for OS X?
Keywords: nsbeta1- → nsbeta1
Keywords: nsbeta1 → nsbeta1-
Depends on: 188508
-> conrad per navtriage email.
Assignee: sgehani → ccarlen
Keywords: nsbeta1- → nsbeta1
QA Contact: sujay → sairuh
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?
Flags: blocking1.4?
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.
Attached patch for navigator (obsolete) — — Splinter Review 
Moves the PP menu item out into platform overlays. Takes care of navigator File
menu and toolbar popup.
Attached patch for mail — — Splinter Review 
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.
Flags: blocking1.4? → blocking1.4+
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
Attachment #122117 - Flags: review+
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [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.
Attached file Suggested help text — 
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?
Attachment #122117 - Flags: superreview-
> 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.
Status: NEW → ASSIGNED
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.
Assignee: ccarlen → sspitzer
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.4final
Attachment #122117 - Attachment is obsolete: true
Attachment #122117 - Flags: review+ → review-
fixed.

this has r/sr=bienvenu

a=sspitzer (it's a 1.4 blocker)
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Keywords: fixed1.4
Resolution: --- → FIXED
Whiteboard: [adt2] → [adt2][fixed on trunk and branch]
Comment on attachment 125196 [details] [diff] [review]
patch

r/sr=bienvenu, a=sspitzer
Attachment #125196 - Flags: superreview+
Attachment #125196 - Flags: review+
Attachment #125196 - Flags: approval1.4+
vrfy'd with 2003.06.09.05-1.4 (branch comm) and 2003.06.09.08 (trunk comm) on os
x 10.2.6.
Status: RESOLVED → VERIFIED
Keywords: fixed1.4 → verified1.4
*** Bug 211053 has been marked as a duplicate of this bug. ***
Depends on: 241066
Depends on: 241067
Depends on: 228000
No longer depends on: 241067
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.
No longer depends on: 228000, 241066
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: