106800 - Number of pages in print job not shown in *nix print dialog

Status: VERIFIED INVALID

(Core :: Printing: Output, enhancement)

Description

[MyBugzillaAcc]

In the print dialog, on Solaris, currently one can not select range of pages 
(e.g., m through m, where m <= n) to print.  This feature is currently lacking 
from the print architecture of the Mozilla based browser.

Comment 1

[Jim Crumley]

Actually, for me Solaris build 2001102522 selecting page numbers does work.  If
you go to a web site that has more than one page and pick 2 to 2, it only prints
the second page.  Unfortunately, the current dialog doesn't tell you correctly
how many pages will be printed.  The selection box always pages 1 to 1, so there
is no way to know how many pages are in the current document (since bug 21432 on
implementing print preview hasn't been fixed either).  This also could be
related to bug 84947 for a better print dialog.

So I'm going to change the summary of this bug to reflect the fact the number of
pages of the print job is not passed in the dialog.  Reporter: if you believe
this is in error, feel free to change it back. This problem present in Linux
(and probably all other *nixes, though possibly not is xprint is used).  

Comment 2

[Alexander Zuev]

I think, that showing pages 1 to 1 in printing dialog is correct behavior. 
Netscape 4 doing this, MS Explorer 5 doing this, even MS Word (which is WYSIWYG, 
Mozilla is not) doing this. To show actual number of pages in print dialog we 
need to proceed print rendering and calculations before dialog shows and do so 
in realtime after changing of every parameter in dialog (orientation, margins, 
paper size). This can be a problem for document with many pages. So, i don't 
think it is a bug.

Comment 3

[Jim Crumley]

I believe this still is a bug, though obviously an extremely low-priority,
enhancement type bug.  If its too difficult to be worth it and someone wants to
mark it as won't fix, that's fine. Obviously, bugs which deal with pages
printing out badly are much important than this.

I don't know what Word does these days (I haven't used it since Word for Windows
2.0), but the situation with a words processor is different.  For a word
processor, the document is broken into pages, so the user knows how many pages
there are.  With a browser - especially one without print preview - there is no
easy way to know how many pages are in a print job. As for what Netscape does,
Netscape 4.X on Unix doesn't even have the page n to page m choice, so there's
no comparison there. And there are programs for Unix that do tell how many pages
will be in a job, such as Adobe acroread, which has the option as "From   To: 
of N" where N is the number of pages in the job.  Of course, it much easer for
acroread since the page breaks have already been chosen by the program that
created the pdf file.

Comment 4

[Alexander Zuev]

>For a word processor, the document is broken into pages, so the user knows how 
many pages there are.  

No, that's not right. For modern editors document is just a set of paragraphs, 
that will be separated into pages on stage of printing, so, number of pages 
depends on printer settings (paper size, orientation, margins, etc.). In modern 
editors splitting into pages shown according to "current" page settings, but 
this is not mean, that user can't change page orientation (for example) in 
print dialog. And number of pages will change. That's why in print dialog of 
editor not shown how many pages will be printed. To know this there are "print 
preview" function.

> And there are programs for Unix that do tell how many pages will be in a job, 
such as Adobe acroread, which has the option as "From   To: of N" where N is 
the number of pages in the job.

And another one is ghostview (PostScript file viewer). That's because both 
programs working with "printing oriented" files (.pdf and .ps). In both formats 
pages splitted on the stage of file creation and by changing of printing 
parameters we can change size of page, but not page layout and number of pages.

> Of course, it much easer for acroread since the page breaks have already been 
chosen by the program that created the pdf file.

Exactly. And this is not true for any HTML browser. Changing of any of the 
printing parameters can lead us to changing of the number of pages. And 
recounting of number of pages in print dialog after changing of any parameter 
for multipage document can take a LOT of time, because to do so we must re-
render for printing the whole document. This is why in modern browsers and 
editors number of pages newer shown in print dialog, only in print preview 
mode. Correct way to print some pages is to set up page preferences, perform 
print preview, look for numbers of pages you want to print and to print pages 
with this numbers with same settings as set in "print preview" mode. This can't 
be done in mozilla, because there are no print preview. But that's what bug 
21432 is all about. And i think that not showing the number of pages in print 
dialog is correct behavior.

Comment 5

[Jim Crumley]

>In modern 
editors splitting into pages shown according to "current" page settings, but 
this is not mean, that user can't change page orientation (for example) in 
print dialog. And number of pages will change. That's why in print dialog of 
editor not shown how many pages will be printed. To know this there are "print 
preview" function.

The point is that if they don't change the settings, the user knows what pages
he will be printing.  I agree that this should really be handled with Print
Preview (really should be bug 20943 I think), but without Print Preview the page
 range selection is pretty much worthless.  This is especially true for Unix
where better functionality can be gained with the correct options to lp/lpr on
the Print Command: line.

> This is why in modern browsers and
editors number of pages newer shown in print dialog, only in print preview 
mode.

Right, and modern browsers and word processors also don't allow changing
settings in the Print dialog.  They do it either in Print Preview or Page Setup.
Since bug 20943 hints at much more progress toward print preview than bug 21432
did this bug is probably moot.  But I still think that if there is a page
selection feature, there should be some way of wkowing how many pages there are.

Comment 6

[Jim Crumley]

Closing since number of pages is now available from Print Preview.  See bug 107562.

Comment 7

[Roland Mainz]

VERIFYING per comment +6 ...