You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2015/11/17 19:46:15 UTC
[Issue 126665] New: Invalid input of "0" prints "ALL" pages
https://bz.apache.org/ooo/show_bug.cgi?id=126665
Issue ID: 126665
Issue Type: DEFECT
Summary: Invalid input of "0" prints "ALL" pages
Product: Writer
Version: 4.0.1
Hardware: PC
OS: Windows 7
Status: UNCONFIRMED
Severity: Normal
Priority: P5 (lowest)
Component: printing
Assignee: issues@openoffice.apache.org
Reporter: tbalsig1@progressive.com
Created attachment 85138
--> https://bz.apache.org/ooo/attachment.cgi?id=85138&action=edit
Attached my recorded steps which displays the printer icon and print
notificiation.
File>Print>Range and Pages> Pages Field -
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.
I have attached my recorded steps.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
oooforum <oo...@free.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |NOT_AN_ISSUE
Status|UNCONFIRMED |RESOLVED
CC| |oooforum@free.fr
--- Comment #1 from oooforum <oo...@free.fr> ---
For me, it's not a bug. Input "0" means "all pages" will be printed.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #4 from tbalsig1@progressive.com ---
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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #7 from Marcus <ma...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #12 from orcmid <or...@apache.org> ---
Created attachment 85146
--> https://bz.apache.org/ooo/attachment.cgi?id=85146&action=edit
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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
orcmid <or...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |orcmid@apache.org
Resolution|NOT_AN_ISSUE |---
Ever confirmed|0 |1
--- Comment #2 from orcmid <or...@apache.org> ---
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?
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #8 from orcmid <or...@apache.org> ---
(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
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #10 from orcmid <or...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #9 from mroe <mr...@gmx.net> ---
(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].
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #11 from orcmid <or...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #6 from mroe <mr...@gmx.net> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #13 from Marcus <ma...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
orcmid <or...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |CONFIRMED
--- Comment #3 from orcmid <or...@apache.org> ---
(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?
--
You are receiving this mail because:
You are the assignee for the issue.
[Issue 126665] Invalid input of "0" prints "ALL" pages
Posted by bu...@apache.org.
https://bz.apache.org/ooo/show_bug.cgi?id=126665
--- Comment #5 from Marcus <ma...@apache.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the issue.