Issue 126665

For me, it's not a bug. Input "0" means "all pages" will be printed.

Excuse me.  This is the report of an usability issue.  For some, 0 is not intuitive as the same as no entry.  Now, I have no idea why 0 was entered and what was expected.  Note that no range was specified.  The implication that 0 is the same as selecting the All pages radio button is a stretch.

It would be more useful if the reporter specified what they had intended to have happen, or was this just an experiment with unusual values in the Pages entry?

(In reply to tbalsig1 from comment #0)

> When a user inputs a "0" Zero in the Pages field and clicks Print, "All"
> pages of document are sent to the printer and printed.  

While your report is accurate, there remains the problem of what *should* the behavior be.  What had you intended to happen?

I was actually testing or "experimenting" with inputting "invalid" values to see what, if any, error message would be produced.  I expected it would reject  the "0" as an invalid value and possibly display a message stating the error and requesting the user add a valid range or page.  I expected that 0 would be printed and certainly did not expect it to default to "All" pages being printed.  

I also left the field "blank" which once again printed "All" pages.  I would once again expect an invalid input error message be displayed and 0 pages being sent to the Printer.  However after reading the response above, I now assume that is expected behavior. 

I think it is a greater risk that a blank field would default to "All" pages being printed than 0.  Users in a hurry get ahead of themselves and accidentally click print before selecting the desired range or pages.  This could result in a 1000 page document be printed.

(In reply to tbalsig1 from comment #4)
> I was actually testing or "experimenting" with inputting "invalid" values to
> see what, if any, error message would be produced.  I expected it would
> reject  the "0" as an invalid value and possibly display a message stating
> the error and requesting the user add a valid range or page.  I expected
> that 0 would be printed and certainly did not expect it to default to "All"
> pages being printed.  

+1

The value "0" in this context must not result in print all pages. And if there will be no error message ina  future release then at least simply send nothing to the printer. The same when the input field is left empty.

> I also left the field "blank" which once again printed "All" pages.  I would
> once again expect an invalid input error message be displayed and 0 pages
> being sent to the Printer.  However after reading the response above, I now
> assume that is expected behavior. 

I hope that this is not "working as designed". ;-)

> I think it is a greater risk that a blank field would default to "All" pages
> being printed than 0.  Users in a hurry get ahead of themselves and
> accidentally click print before selecting the desired range or pages.  This
> could result in a 1000 page document be printed.

Right, maybe it's not (easily) possible to cancel this print job. And then user has a big problem.

If *think* that fast fix is pretty easy: Catch the input event if there is a "0" or empty field, then do nothing.

The more advanced fix is to show first an error message with just an [OK] button. A bit advanced because this has to be designed a bit and translated into every language.

(In reply to Marcus from comment #5)
> I hope that this is not "working as designed". ;-)

I think so. Because it it has never been otherwise.

But there was a time where the behaviours of StarOffice was better documented. Please click [Help] and wonder …

> If *think* that fast fix is pretty easy: Catch the input event if there is a
> "0" or empty field, then do nothing.

I doesn't think so.

1. I believe that there is other software with the same behaviour.
2. The input is text, not a number. "-5" doesn't mean "Print page -5". It means "Print (from the first) to the fifth page."
3. It is the definition: blank or 0 means "All".
If not so: what should mean "All"?
4. What is the benefit if anybody click [Print] and nothing happens?

For me it is clearly a documentation issue.

(In reply to mroe from comment #6)
> (In reply to Marcus from comment #5)
> > If *think* that fast fix is pretty easy: Catch the input event if there is a
> > "0" or empty field, then do nothing.
> 
> I doesn't think so.
> 
> 1. I believe that there is other software with the same behaviour.

that's nice but shouldn't matter here as I'm sure that we want to create something on our own and not to copy others. ;-)

> 2. The input is text, not a number. "-5" doesn't mean "Print page -5". It
> means "Print (from the first) to the fifth page."

OK, then it's a text input field.

> 3. It is the definition: blank or 0 means "All".

Which is wrong IMHO.

> If not so: what should mean "All"?

If you want to print all pages, then click the radio button "All pages" or simply keep the input field unchanged when you open the print dialogbox. ;-)

> 4. What is the benefit if anybody click [Print] and nothing happens?

The benefit is that not all pages are print as it is not expected (see comments above).
> 
> For me it is clearly a documentation issue.

Sure, the documentation has to be at least extended. But this wouldn't change the user expectation. There has to be also a fix in the code - like suggested.

Again:
Also for me it is strange that "0" or an empty field will result in a full print.

(In reply to Marcus from comment #7)
> (In reply to mroe from comment #6)
> > (In reply to Marcus from comment #5)
> > > If *think* that fast fix is pretty easy: Catch the input event if there is a
> > > "0" or empty field, then do nothing.
[ ... ]> If you want to print all pages, then click the radio button "All pages" or
> simply keep the input field unchanged when you open the print dialogbox. ;-)
> 
> > 4. What is the benefit if anybody click [Print] and nothing happens?
> 
> The benefit is that not all pages are print as it is not expected (see
> comments above).
> > 
> > For me it is clearly a documentation issue.
> 
> Sure, the documentation has to be at least extended. But this wouldn't
> change the user expectation. There has to be also a fix in the code - like
> suggested.
> 
> Again:
> Also for me it is strange that "0" or an empty field will result in a full
> print.

I agree that any solution to peculiar entries in the Pages field, including no entry with the Pages radio button selected, should provide absolute minimum surprise and the least disruptive action.  Printing an entire file does not qualify.

There are many ways to solve this.  

First, we need to look at all of the possible strange inputs.  It is just not a single "0" or blank field that is a problem.  There are many ways to write a sequence of page selections that do not lead to some selection of actual pages being identified for printing (once).  There are many ways to indicate that there is no understood choice, and disabling the Print button could include some of them.

What more ideas are there about how to handle this in the simplest but least dangerous manner?



k

(In reply to orcmid from comment #8)
> > Again:
> > Also for me it is strange that "0" or an empty field will result in a full
> > print.
> 
> There are many ways to solve this.  

The first (and IMHO only) thing to do is to update the preview on the left side with the right result. The output "no pages" is simply wrong if anybody type "0" into the pages field. It should be the same as for "0-".

Because there wasn't a preview before OOo 3.3(?) nobody found the behaviour faulty.


BTW: The only help for the input into the pages field one can find if one press [Shift]+[F1].

(In reply to mroe from comment #9)
> (In reply to orcmid from comment #8)
> > > Again:
> > > Also for me it is strange that "0" or an empty field will result in a full
> > > print.
> > 
> > There are many ways to solve this.  
> 
> The first (and IMHO only) thing to do is to update the preview on the left
> side with the right result. The output "no pages" is simply wrong if anybody
> type "0" into the pages field. It should be the same as for "0-".
[ ... ]

When I am printing out items for file, such as order confirmations from amazon.com, the email will often take 2 pages (many more from other vendors) although everything I need is on page 1.

Since I had this "0" business fresh in mind, I tried 0 in the Pages entry for printing the confirmation of a just-made order.  'Lo, my Microsoft Outlook didn't print anything.

The preview didn't change -- that is what I used to know everything I needed would be on the first page.

Although it is a weird case, I wonder how accessibility aids would describe an entry of "0" there.  

Maybe that's the safest answer.  When there are no pages in the specified pages (range), perhaps there is nothing to print.  One might want to maybe be a little more helpful, but not printing anything certainly qualifies as a non-dangerous response.

(In reply to orcmid from comment #10)
> (In reply to mroe from comment #9)
> > (In reply to orcmid from comment #8)
> > > > Again:
> > > > Also for me it is strange that "0" or an empty field will result in a full
> > > > print.
> > > 
> > > There are many ways to solve this.  
> > 
> > The first (and IMHO only) thing to do is to update the preview on the left
> > side with the right result. The output "no pages" is simply wrong if anybody
> > type "0" into the pages field. It should be the same as for "0-".
> [ ... ]
> 
> When I am printing out items for file, such as order confirmations from
> amazon.com, the email will often take 2 pages (many more from other vendors)
> although everything I need is on page 1.
> 
> Since I had this "0" business fresh in mind, I tried 0 in the Pages entry
> for printing the confirmation of a just-made order.  'Lo, my Microsoft
> Outlook didn't print anything.

Inspired by that, I opened a multi-page .doc file in Microsoft word and entered "0" in the Pages field.  Same behavior -- quietly not printing anything.  

BEST YET: I opened the PDF version of the same multi-page document in the just-release Acrobat Reader DC.   When I clicked Print in the print dialog, for Pages set to "0".  Nothing printed.  But the print dialog stayed open, with nothing changed.  NICE.

Created attachment 85146 [details]
Acrobat Reader DC Handling of Invalid Pages Ranges

(In reply to orcmid from comment #11)

> BEST YET: I opened the PDF version of the same multi-page document in the
> just-release Acrobat Reader DC.   When I clicked Print in the print dialog,
> for Pages set to "0".  Nothing printed.  But the print dialog stayed open,
> with nothing changed.  NICE.

My mistake.  The above behavior was from the Windows Edge browser using its embedded PDF support.  This is likely to be a common dialog in the new-style of "Universal" applications though.

When I corrected the .pdf file association to use Acrobat Reader DC, I achieved an even better result.  When I used "0" in the page-ranges option, I received a message box that rejected the invalid page-range value.  The attachment illustrates that case.

I think the silent no-action case, leaving the dialog up, is the simplest safe case.  One with a message about it is better.

(In reply to orcmid from comment #12)
> Created attachment 85146 [details]
> Acrobat Reader DC Handling of Invalid Pages Ranges
> 
> (In reply to orcmid from comment #11)
> 
> > BEST YET: I opened the PDF version of the same multi-page document in the
> > just-release Acrobat Reader DC.   When I clicked Print in the print dialog,
> > for Pages set to "0".  Nothing printed.  But the print dialog stayed open,
> > with nothing changed.  NICE.
> 
> My mistake.  The above behavior was from the Windows Edge browser using its
> embedded PDF support.  This is likely to be a common dialog in the new-style
> of "Universal" applications though.
> 
> When I corrected the .pdf file association to use Acrobat Reader DC, I
> achieved an even better result.  When I used "0" in the page-ranges option,
> I received a message box that rejected the invalid page-range value.  The
> attachment illustrates that case.
> 
> I think the silent no-action case, leaving the dialog up, is the simplest
> safe case.  One with a message about it is better.

I don't know if it's technically possible to have a message box above another box. But if yes, then it's the solution I would prefer. Otherwise to keep the Print dialog simply open is also not bad.