20943 - [FEATURE] Print preview needs to be hooked up on mac

Status: VERIFIED FIXED

(Core :: Printing: Output, enhancement, P2)

Description

[shrirang khanzode]

I used the latest commercial build for today . Did the following:

1) Start mozilla
2) Go to a page on mozilla.org
3) Open the File menu.
4) I see the Print Preview option grayed out and unusable.

However,I see this option enabled in Composer. But clicking on it opens a very
small fixed-size window(showing no contents).

Comment 1

[dcone (gone)]

Print preview needs to be hooked up.

Comment 2

[Chris McAfee]

mcafee

Comment 3

[Chris McAfee]

mcafee

Comment 4

[don]

Not required for beta.

Comment 5

[don]

Move to M16 for now ...

Comment 6

[shrirang khanzode]

Print Preview was supposed to be in for Beta1 as per the marketing document. 
Then why is it being moved to "Future" ?

Comment 7

[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 8

[Chris McAfee]

m17

Comment 9

[don]

Move to M19 target milestone.

Comment 10

[leger]

Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature 
train.  Please set to MFuture

Comment 11

[Niko Pavlicek]

I used this feature in NS 4.x frequently and I know many users dit it? Why
nobody is interested in finishing this feature as quickly as possibly?

Comment 12

[Jason Eager]

Adding myself to cc.

Comment 13

[Paul Chen]

nav triage team:
great feature, but we have bigger fish to fry

Comment 14

[Daniel Veditz [:dveditz]]

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

Comment 15

[Jason Eager]

Adding keyword "4xp", because pretty much all other browsers have this. I don't
think we're going to get a positive reception if we ship without this.

Comment 16

[Blake Ross]

bleh.  Netscape's had print preview for years, IE finally adds it, and we 
remove it.

How do things like this happen? This was reported in December '99, and it seems 
like no one really woke up and said 'hey, no one's started on print preview 
yet' until August '00.  Apparently no progress was ever made towards the 
feature (judging from the complete lack of engineering comments in this bug).  
Anyways, I'm not saying we should do this for beta3 or RTM, it just seems like 
no time was ever budgeted for this feature to begin with.

Comment 17

[Niko Pavlicek]

we have 3 votes for this bug, any other browser has it, and the nav triage team
just says: "great feature, but we have bigger fish to fry"!
It is big ****, that the "next generation-browser" has just a basic
print-feature. There are even no page headers and footers like in every other
browser!
It cannot be real, that nobody is interested in doing this.

Comment 18

[timeless]

Wonderful. IE5.5 finally gets print preview.
Netscape's response: N6 won't have it.

Brendan: this is a case of a bug that should have been addressed when it was 
filed.

I know i'm in no position to declare priorities for netscape, but Marketing 
said beta1. The world forced microsoft to do this. The original bug acts like 
there was very little to do. Something went terribly wrong in this process.

Nominating RelnoteRTM: "Netscape 6 does not have Print Preview; It is a what 
you see is what you get application, so maybe the page view is what would 
print. Please use some other browser for this purpose, or maybe print to a file 
and then load it back into Netscape 6"

Comment 19

[Brendan Eich [:brendan]]

I don't know why this bug has starved.  It blocks other bugs higher in the 
system, but maybe it is blocked by a lower-level bug not listed in "depends on". 
mcafee, what's the scoop?

There will be many things that cause people to shake their heads about Netscape 
priorities; shame on netscape.com if these failures to implement something are 
truly shameful.  Lacking other developers to do the work, mozilla.org can only 
stand back and let bad reputation attach to the dominant contributor.  That's 
not constructive (it hurts mozilla.org too); it would be better to get other 
developers on the case.  Suggestions?

/be

Comment 20

[Chris McAfee]

pinged dcone about how I'm supposed to hook this up.

Comment 21

[Chris McAfee]

Attachment: New function from [e-mail]

Comment 22

[Niko Pavlicek]

just adding me to cc!
and: has someone looked at the attachment? and: why is the status of this bug
still NEW and not CONFIRMED? and: why is the Target Milestone Future, if the
Severity is major and the Priority P2?

Comment 23

[Brendan Eich [:brendan]]

The attachment has some badly wrapped lines, but otherwise does it work?  What
else needs to be done?  9/24 seems like ages ago, but it was only a few weeks.

/be

Comment 24

[Chris McAfee]

be:  This just fell off my list.  Nominating for rtm+.

Comment 25

[don]

This was latered out of Netscape 6 beta 3 because we (me and the rest of the
Navigator triage weasels) were waiting on help from the back-end folks.  It's
completely our fault (mostly mine) that we didn't notice the fix had gotten in.

I would LOVE to have mcafee land this the mozilla trunk.  If it's stable,
perhaps the PDT will take it for Netscape 6 RTM.  But has anybody tried running
with the patch yet?  Does it work for non-browser windows?  Can we get the two
pre-requisite reviews for this, at least?

Comment 26

[Blake Ross]

testing the fix now...

Comment 27

[Blake Ross]

hmm, so, what am I doing wrong here?

C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1496) : error 
C2065: 'NS_WEBBROWSER_PROGID' : undeclared identifier
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1499) : error 
C2530: 'lt' : references must be initialized
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1499) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1499) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1500) : error 
C2065: 'webBrowserWin' : undeclared identifier
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1500) : error C2227: left 
of '->InitWindow' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1503) : error C2227: left 
of '->Create' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1506) : error 
C2086: 'lt' : redefinition
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1506) : error 
C2530: 'lt' : references must be initialized
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1506) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1506) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1507) : error 
C2086: 'lt' : redefinition
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1507) : error 
C2530: 'lt' : references must be initialized
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1507) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1507) : error C2143: 
syntax error : missing ';' before '>'
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1508) : error 
C2065: 'webShell' : undeclared identifier
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1508) : error C2227: left 
of '->SetContainer' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1509) : error C2227: left 
of '->GetDocumentLoader' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1509) : error 
C2065: 'docLoader' : undeclared identifier
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1511) : error C2227: left 
of '->AddObserver' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1513) : error C2227: left 
of '->SetVisibility' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1544) : error C2227: left 
of '->Embed' must point to class/struct/union
C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1545) : error C2227: left 
of '->SetVisibility' must point to class/struct/union

I fixed the couple of formatting errors that came as a result of c&p.

Comment 28

[Blake Ross]

argh..I should've looked closer.  For anyone else trying out the fix, be sure 
to change '&lt;' in the attached code to '<'.  I assume the file was attached 
as plain/text, so that didn't properly show up.

However, I'm still getting this error:

C:\mozilla\webshell\tests\viewer\nsBrowserWindow.cpp(1496) : error C2065: 'NS_WE
BBROWSER_PROGID' : undeclared identifier
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~4\VC98\BIN\cl.exe' : return code
'0x2'
Stop.

Comment 29

[Peter Trudelle]

Do we really want this feature on all platforms?  It is of little or no use on
at least one platform without Page Setup (bug 36796 and bug 42817).  Adding
print preview on the Mac, where we never had it before, without any way to
change the settings would be ironic at best.

Comment 30

[lchiang]

For future reference, please attach the test plans/cases for this feature.

Comment 31

[Niko Pavlicek]

at least we need it on Windows, where it had been since NS 4.x and I think
especially the "black text"-option is a MUST BE if you want to print pages with
dark backgrounds with originally very light text.
Also, I think it could be useful on some pages to just print it without any
stylesheets and so on.

Comment 32

[Chris McAfee]

trudelle: we should fix both page setup and print preview.
It would be useful on all platforms, if we didn't have it before
then we've had crappy printing support before.  Maybe this isn't
1.0 material but we should get it in if/when a fix/implementation
is ready.

Comment 33

[timeless]

cc{mac users}:
do we really not want print preview [and print setup] on macos?
this bug is helpwanted and i guess it needs some love from some mac users.
keywords: platform parity.

Comment 34

[Matthew T (active 1999-2002)]

The long-term plan is not to have Page Setup anyway, since it's hardly any use
<http://www.pp.htv.fi/hsivone1/print-ui.html>, but instead to have a `Print
As ...' window which consists of a print preview with controls for altering the 
printing options with a dynamically-updating preview (e.g. fonts, background 
colors, style sheet, and so on). This is the approach employed by both IE 5 and 
iCab on Mac OS, and it works very well.

Even without such options, a vanilla Print Preview would be very useful right now 
for letting you know (for example) that the last page of your document contains 
only footer fluff and does not need to be printed.

Comment 35

[timeless]

"Print As" *cough* *gasp* *choke*.
watches as someone tries to Print As genuine Canadian 10 Dollar Bill.

Also, "Save As Charset" is wrong. The correct words for either should fix both.

Maybe Print Formatted and Save Formatted ?

Comment 36

[don]

This is getting too late for N6 RTM.  Especially with the Page Setup issues.
Sorry.  I would really like to have this, but ... ***sigh*** ... minus.

Comment 37

[rvj]

As a XUL applications developer, I need to be able to build consistant printer 
handling facilities across all platforms

I was a little unsure about the implications of the Print As future? Matthew 
Thomas (mpt) 2000-10-10 08:10 

As long as there is a full javascript interface (api) to a general purpose 
printer engine I am happy. 

At the moment the printer engine seems to embed specific application calls such 
as  printEngine.AddPrintURI(uriArray[i]) rather than something much simpler. 

My javascript priorities as follows

1. A print method to be started without displaying a print dilaog box.(quiet 
mode)

var pid = print.start(iframeid,'nodialog')

where the contents of the iframe may have been created by DOM + javascript

2. Acess to the page setup and the properties of the default printer

print.orientation=landscape;
print.copies=1;
print.header="title";
print.footer="Page"+print.pagecount;

3. A preview facility - either a new xul element or show the preview in IFRAME 
and use CSS attributes to size (50%)

4. A method that can  identify the current or optional devices (if possible)

array printers[] = printer.list()

5. change the default printer (if possible)

printer.default (printers[1])

6. Cancel print job (if possible)

print.cancel(pid)

Comment 38

[Joseph Elwell]

Print preview saves trees.

Comment 39

[Blake Ross]

possible to do this for beta1, since we've got a prototype?

Comment 40

[Viswanath Ramachandran]

reassign to law. 

Comment 41

[Charles Manske]

Adding myself to CC list and removing Simon. I have the dependent editor bug 21432

Comment 42

[Chris McAfee]

dcone: I remember you saying there was a better way to do this than the
attachment from 9/2000 that is in this bug, probably why I didn't check it in. 
Comments?

Comment 43

[shrirang khanzode]

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

Comment 44

[Bill Law]

Resetting target milestone to match keyword.  I'm supposed to assess print
preview during .8 timeframe to ensure we can complete it by .9.  Still up in the
air, though...  Need info on how to hook it up in viewer!

Comment 45

[Robert Pollak]

As Boris Zbarsky asks there: Is bug 37359 a duplicate? Or dependent?

Comment 46

[Bill Law]

This bug is about Print Preview in Mozilla, not viewer.  So it is not a dup.
I'm claiming this bug is dependent on that one (to implement this in Mozilla, I
have to, at a minimum, understand how it works, and getting it to work in viewer
is highly correlated.

Comment 47

[Jesse Ruderman]

Ways to access print preview should include:
- Alt+F+V (to match IE and wordpad)
- Ctrl+Shift+P

Comment 48

[dcone (gone)]

I don't think it is nessisary to get bug 37359 working in viewer.. the patch is 
posted in that bug.. that example can be put in your code, and gives examples of 
how to implement that for Mozilla.  I will not be putting that in viewer for a 
while.

Comment 49

[Bill Law]

Help!  I can't even figure out how to put that example in viewer, let alone in
Mozilla.

"My code" is going to be something like printPreview.js.  My theory is that I'll
have to extend some embedding interface to take an argument that will tell it to
do whatever it needs to do to get the appropriate print preview pres context
created.

But I don't have a clue about where to put that code.  If viewer.exe did print
preview, then I'd at least have a clue, if nothing else.

Comment 50

[Paul Chen]

Mass moving most of mozilla0.9 bugs to mozilla0.8.1

Comment 51

[Paul Chen]

Bill Law is swamped, reassigning to pchen. This one is most likely going to be
pushed back to mozilla0.9

Comment 52

[Paul Chen]

Grrr, ran out of time for mozilla0.8.1, moving to mozilla0.9

Comment 53

[Paul Chen]

Ok, so there was a print preview meeting about a week and a half ago, the upshot 
is that there is still low-level work that needs to be done in the presentation 
layer to support print preview. There is currently no resource available to 
implement this, so it doesn't look like print preview is going to happen for 
beta1. Marking nsbeta1- and setting target milestone to future.

Comment 54

[Doron Rosenberg (IBM)]

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

Comment 55

[Dwayne]

Current vote status: 27 (Don't forget to vote!  Easier than election day!)

Isn't there a way to just use the basic rendering engine in a so-called
'miniature' mode?  Not only would it be easy to implement IMO (just scale the
rendering), but it would be the most exact.  Am I missing something here?

We already have the ability to change the size of almost every element down to
the pixel level; why not use some type of subsampling trick to create an
anti-aliased full-page render?

Just some thoughts...

Comment 56

[dcone (gone)]

print preview is exactly that, just like printing is.  That would currently 
work, but there are other issues, like page number to look at, pagenation, 
current selection, a window to view it in, etc.  Your missing the GUI, which 
is not a small task.. 

Comment 57

[Manoj]

This is about PRINT PREVIEW:
              --------------
When moving from one version to another, the good features of an older version
should be preserved and more features should be added. This hasn't been the
philosophy of Mozilla all along. There was a time when Mozilla did not support
the dragging of URLs into the personal toolbar (to create new bookmarks) the way
Netscape 4.x did. IE has been good at taking all that was better in Netscape and
adding it to its product, making it a marriage of the best of both worlds. But
Mozilla instead is going the other way. i am glad Mozilla 0.9.1 supports the
creation of bookmarks in the Personal Toolbar like N4.x. Why has Print Preview
been removed? This is strange and quite frustrating at times, to see that IE has
copied something that Netscape did so well but doesn't do anymore. Developers,
don't you want users to ACTUALLY use your product??

Comment 58

[Alex Bishop]

A long, long time ago (late 1998), the decision was made to write Mozilla from
scratch. The existing codebase (dubbed MozillaClassic) that had been used to
create Netscape Navigator 1-3 and Netscape Communicator had come a long way but
was no longer up to the job (especially the rendering engine, which was
revolutionary in 1994, but no longer cut it in 1998). So it was abandoned.

As a result of this, all the exisiting features had to be recreated - it isn't
as simple as just transferring the code from the old codebase to the new one
(due to differences in how they work).

It would have been possible to make Mozilla from MozillaClassic, but this
eventually leads to bloated inefficent code (as Windows - which contains code
from the early Eighties - shows).

Comment 59

[Blake Ross]

What the heck is this bug doing futured?  It continues to be one of the top 3
requests/complaints, as it was in 6.0.

Don, can you explain the attached code?  How does it help?

Comment 60

[Jussi-Pekka Mantere]

Removing nsenterprise nomination.

Comment 61

[Keyser Sose]

I don't know why this is still futured but I am getting lots of pressure from
people who are trying out Mozilla and love it but there one big complaint is the
lack of the Print preview feature.....cant this be moved up a bit? What holding
up/Needs to be done?

Comment 62

[Todd Pringle]

Paul, Vishy,

We need to move this in, IMO - and possibly reassign to Don Cone.  I don't think
we have the back end to hook up to based on the last go-around with this, but
Print Preview is high on the priority list.  I think Don and Bill arrived at a
how to implement concept, but we ran out of time.  Mozilla 1.0?

Comment 63

[Paul Chen]

nav triage team:

Marking nsbeta1+ and mozilla1.0.1. We need to find out how far layout support
for this feature has come along (if at all).

Comment 64

[Kevin McCluskey (gone)]

CC'ing Rod. He is implementing the print preview backend

Comment 65

[Pratik]

Wow. So this bug is finally actually getting some attention? When can we expect 
this very-important-feature to become available? (Please tell me you guys will 
have it in by 1.0 and not 1.0.1)

Comment 66

[rcummins]

If the basic print preview is in by 1.0, here are some features to shoot for in
1.0.1 :)

http://www.fineprint.com/software/fineprint/standard/benefits.html

Oh, how mightily Mozilla would then kick butt...should I open bugs for these
enhancements, or wait until they wouldn't be dependent on this bug?

Comment 67

[Greg K.]

Be sure not to apply this feature to Fizzilla (Mac OS X), since Print Preview is
an OS-level function there we don't need to duplicate.

Comment 68

[Jonadab the Unsightly One (Nathan Eady)]

Adding myself to the CC list, since my coworkers and our 
patrons are complaining regularly about the lack of this 
feature, it is the second most common complaint.  (The 
most common being, "this page won't print", which usually 
involves either white text or active content, and I don't 
feel as bad about that since other browsers don't do well 
there either.)

Comment 69

[Peter Trudelle]

Moving to mozilla0.9.7, marking blocks 75643

Comment 70

[Peter Trudelle]

Turning this into a feature tracking bug for implementing this in MachV. Adding
dependency on Navigator feature tracking bug 102472.  

    *  Print Preview Option in File Menu.
    * Functionality that includes:
          * Access from Preview screen to Print and Page Setup.
          * Page Advance - back and forth, single page and beginning/end.

      Have plan for Navigator-only, dependency on back-end work.

http://mozilla.org/xpapps/MachVPlan/Print_Preview.html

Comment 71

[Alex Bishop]

Spam: Hurray!

The plan mentions "galley mode". Should that be "gallery mode"? The only
definition of 'galley' I can find is "A low flat-built sea-going vessel with one
deck, propelled by sails and oars, formerly in common use in the Mediterranean"
(OED). That and some operating system.

Comment 72

[Peter Trudelle]

I think the derivation is a mode which displays the content as in a galley
proof.  See http://www.writersmarket.com/encyc/g.asp

Comment 73

[Alex Bishop]

Thanks. I'd never come across that definition before.

Comment 74

[Jonadab the Unsightly One (Nathan Eady)]

Heads up:  see bug 107562.  Stuff is happening.  

Comment 75

[Paul Chen]

Changing summary to "[FEATURE] Print preview needs to be hooked up on mac"

Comment 76

[Paul Chen]

Attachment: patches to get print preview working on mac

Comment 77

[rods (gone)]

Very cool!  r=rods (I was hoping it would be that small of a change)

Comment 78

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

Comment on attachment 58118 [details] [diff] [review]
patches to get print preview working on mac

sr=[e-mail] (also checking 'review' for rods)

Comment 79

[Paul Chen]

fix checked into trunk

Comment 80

[Boris Zbarsky [:bzbarsky]]

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

Comment 81

[sujay]

Just tried Print preview on 11/20 trunk build on Mac.

I get the busy cursor....print preview window never comes up.

can someone else try the print preview on Mac 9.x/OSX and report
back here on whether it works or not for them?

thanks

simple steps:

1) launch netscape
2) jump to home.netscape.com
3) File | Print Preview

Comment 82

[Yuying Long]

It was worked fine with me on 11-19 trunk build on both Mac OS X and 9, haven't
tried today's build though.

Comment 83

[Peter Trudelle]

There shouldn't be any new window, this feature is more like MS Word's Print
Layout, which I think used to be called Document View.

Comment 84

[sujay]

the problem I desribed earlier no longer happens.

verified on 11/20 trunk build.