Bug 122710 - PRINT DIALOG: For "Pages to print" field interpret space as separator for a list of distinct pages to print
Summary: PRINT DIALOG: For "Pages to print" field interpret space as separator for a l...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2019-01-14 16:37 UTC by Ulf Zibis
Modified: 2020-11-19 11:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
current draft of proposed help page on print selections (62.36 KB, image/png)
2020-11-18 08:35 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulf Zibis 2019-01-14 16:37:37 UTC
Description:
Unexpected huge amount of printed pages.

Steps to Reproduce:
1. Open Print dialogue.
2. Enter a couple of numbers in the "Pages to print" field, separated by space character.
3. Start print.

Actual Results:
All pages from the smallest to the biggest number are printed.
A space character in the "Pages to print" field is interpreted as "form .. to". This is not intuitive, and wastes a lot of paper.

Expected Results:
Only the entered pages should be printed.
A space character should be interpreted as separator for a list of distinct pages to print.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Oliver Brinzing 2019-01-15 17:23:15 UTC
currently pages are separated via semicolon:

>This range is given as at the user interface. 
>For example: "1-4;10" to print the pages 1 to 4 and 10. 
>https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1view_1_1PrintOptions.html#a35ceecc65a2f7e250d091fef88f8ece6

IMHO data entered via user interface could be validated before printing
Comment 2 sdc.blanco 2020-11-09 11:51:35 UTC
Calling attention to a simple, but presumably not intended feature. 
Adding needsUXEval.  Maybe Easy Hack to repair?

Restatement of problem:

Assume 10-page document.

1. In Print dialog, select Pages (in Range and Copies)
2. Enter:  4 7
3. Print (or see Print Preview)

Result:  Pages 4 to 7 are printed.

4.  Enter 1 3, 7 9

Result:  Pages 1,2,3,7,8,9 are printed.

(comment 1 goes further and suggests "validation" of entered strings)
Comment 3 Heiko Tietze 2020-11-09 12:38:50 UTC
Without reading the help I'd expect dash, colon, and perhaps also "horizontal colon" being the wildcards and comma or semicolon as separator. The inline help of the control says "1,3-5,7;9" and additionally I get an empty preview with my horizontal colon approach. So feedback is sufficient.

However, "1 2, 5" prints three pages while "1, 2 5" does five => bug (everything after the comma/semicolon is a range). In fact "1 3" prints three pages and "1 3,5 7" six. Meaning the space equals a dash.

We could solve the issue by requesting commas or semicolons between individual pages and dashes for a range. A space wouldn't be possible anymore. Or we treat space, comma, semicolon as the same, which might be what the OP expected (and I agree). Or we accept space being a replacement of the dash and make it clear in the (missing) documentation.
Comment 4 sdc.blanco 2020-11-09 12:58:40 UTC
(In reply to Heiko Tietze from comment #3)
> We could solve the issue by requesting commas or semicolons between
> individual pages and dashes for a range. A space wouldn't be possible
> anymore. 
+1  (consistent with existing tooltip, and Writer's Guide).

> Or we treat space, comma, semicolon as the same, which might be
> what the OP expected (and I agree). 
OP was "objecting" to "space" as equal to comma and semicolon.

From comment 0: "not intuitive, and wastes a lot of paper."

> and make it clear in the (missing) documentation.
Coming soon... (-:
Comment 5 Michael Weghorn 2020-11-12 16:34:03 UTC
(In reply to sdc.blanco from comment #4)
> (In reply to Heiko Tietze from comment #3)
> > We could solve the issue by requesting commas or semicolons between
> > individual pages and dashes for a range. A space wouldn't be possible
> > anymore. 
> +1  (consistent with existing tooltip, and Writer's Guide).

+1

(maybe allowing and ignoring spaces, but not as only separator between two digits, so e.g. "1-3, 4" would be OK, but "1-3 4" wouldn't)

This also matches what Gtk and Qt print dialogs do. When I enter "1 4 5" there, both show an error dialog, saying: "1 4 5 does not follow the correct syntax. Please use ',' to separate ranges and pages, '-' to define ranges and make sure ranges do not intersect with each other."
Comment 6 Ulf Zibis 2020-11-12 22:35:57 UTC
I would like:
1. Separators:       ',' ';'
2. Range specifiers: '-' ':'
3. Allow half defined ranges
4. Also allow space as separator, but only if directly surrounded by numbers, otherwise ignore it. This is, because space is commonly used as separator or just after ',' or ';', but maybe don't officially mention space as separator in the short tooltip.

Examples:
1:3 5     print pages 1, 2, 3, 5
1,3 5     print pages 1, 3, 5
1 3-5     print pages 1, 3, 4, 5
1 3 5     print pages 1, 3, 5
1, 3, 5   print pages 1, 3, 5    (ignore spaces)
1 3 - 5   print pages 1, 3, 4, 5 (ignore spaces except 1st)
1  3;5    print pages 1, 3, 5    (ignore first space, so the 2nd remains surrounded by numbers)
 -3       print pages 1, 2, 3    (ignore first space, start range at 1)
1 ; 3 -   print pages 1, 3, ...  (ignore spaces, complete range up to last page)

Main rule: If the definition seems semantically ambiguous, never waste paper for possibly unwanted pages. the user can always do a 2nd run if pages are missing.
Comment 7 Michael Weghorn 2020-11-13 06:49:33 UTC
(In reply to Michael Weghorn from comment #5)
> This also matches what Gtk and Qt print dialogs do. When I enter "1 4 5"
> there, both show an error dialog, saying: "1 4 5 does not follow the correct
> syntax. Please use ',' to separate ranges and pages, '-' to define ranges
> and make sure ranges do not intersect with each other."

To correct myself: Actually, only the Qt print dialog shows this error message. (I had GTK_USE_PORTAL=1 set when quickly testing, so the Gtk applications I was testing were also using the Qt print dialog...).
When using the Gtk print dialog (tested with gedit), "1 4 5" just prints the first page, which is not what I'd have expected.

In general, I'd suggest to be consistent with what other print dialog implementations (like Gtk or Qt or native Win/Mac print dialogs) do, which IMHO will help to avoid confusion for users.

(In reply to Ulf Zibis from comment #6)
> I would like:
> 1. Separators:       ',' ';'

Sounds good to me.

> 2. Range specifiers: '-' ':'

I wouldn't introduce ":" as additional range specifier, it wouldn't be clear to me. Gtk handles it as a separator...

> 3. Allow half defined ranges

That's an interesting thought.

> 4. Also allow space as separator, but only if directly surrounded by
> numbers, otherwise ignore it. This is, because space is commonly used as
> separator or just after ',' or ';', but maybe don't officially mention space
> as separator in the short tooltip.

I tend to not allow space as separator (e.g. Gtk and Qt don't handle it that way)

> Main rule: If the definition seems semantically ambiguous, never waste paper
> for possibly unwanted pages. the user can always do a 2nd run if pages are
> missing.

I have a strong preference to reject ambiguous/invalid page specifications (e.g. by showing a dialog) and allow the user to correct that BEFORE printing anything that the user might not expect, which would IMHO be the most effective and least confusing way to avoid printing unwanted pages.
Comment 8 Ulf Zibis 2020-11-13 22:37:17 UTC
(In reply to Michael Weghorn from comment #7)
> In general, I'd suggest to be consistent with what other print dialog
> implementations (like Gtk or Qt or native Win/Mac print dialogs) do, which
> IMHO will help to avoid confusion for users.
As far as I remember, Windows dialogues accept space as separator, so as common usage IMHO it will confuse people, when space is no more accepted.

> (In reply to Ulf Zibis from comment #6)
> I wouldn't introduce ":" as additional range specifier, it wouldn't be clear
> to me. Gtk handles it as a separator...
To me it is not important, but maybe others could miss it, so we could allow it undocumented.

> > 3. Allow half defined ranges
> That's an interesting thought.
Thanks.

> I tend to not allow space as separator (e.g. Gtk and Qt don't handle it that
> way)
How do they handle it?

> I have a strong preference to reject ambiguous/invalid page specifications
> (e.g. by showing a dialog) and allow the user to correct that BEFORE
> printing anything that the user might not expect, which would IMHO be the
> most effective and least confusing way to avoid printing unwanted pages.
As far as I can think, there is no ambiguity left with rule 4. I just meant the human interpretation could seem ambiguous, but at least the user can see the effective result with the preview.
Main rule: Never print more pages than user could imagine.
Comment 9 Ulf Zibis 2020-11-13 22:43:12 UTC
I'm not a friend of error messages about strict syntax faults. If the intention of the user is clear, even if syntactically not typed strictly correct, just do the print without interruption.
Comment 10 Heiko Tietze 2020-11-16 10:39:12 UTC
(In reply to Ulf Zibis from comment #9)
> I'm not a friend of error messages about strict syntax faults.

Definitely not. If the user writes "Hello World" into the range she wouldn't get any preview, which makes it very clear. This shouldn't change. 

In respect to comment 6, I fully agree with 1) and 2) but not 3) (additional effort, more complexity), and object to 4) because "allow space, but only if" might be easy to understand for people who discuss the topic but not the average user.
Comment 11 Michael Weghorn 2020-11-16 13:43:52 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Ulf Zibis from comment #9)
> > I'm not a friend of error messages about strict syntax faults.
> 
> Definitely not. If the user writes "Hello World" into the range she wouldn't
> get any preview, which makes it very clear. This shouldn't change.

... if she has the print preview enabled and looks in that area. But why would anyone want to press "OK" when they know that what they entered is invalid anyway?

> In respect to comment 6, I fully agree with 1) and 2) but not 3) (additional
> effort, more complexity),

Just tested this. It looks like 3 already works, e.g. entering e.g. "-2" selects pages 1 and 2 in a 20 page document.

> and object to 4) because "allow space, but only
> if" might be easy to understand for people who discuss the topic but not the
> average user.

If we don't reject invalid input, I'd say we should be doing *something* with spaces in this case (or we just say that we always just don't print anything when something like this is entered, but as as a user I'd be much less surprised to get some kind of explicit information).
Comment 12 Ulf Zibis 2020-11-16 21:07:05 UTC
(In reply to Heiko Tietze from comment #10)
> ... and object to 4) because "allow space, but only if" might be easy to
> understand for people who discuss the topic but not the average user.
For this reason, I suggest to not explicitly offer such escape rule in the tool tip, but allow such spaces in hidden manner, as a kind of error tolerant "fuzzy logic".

(In reply to Michael Weghorn from comment #11)
> > ... 3) (additional effort, more complexity),
> Just tested this. It looks like 3 already works, e.g. entering e.g. "-2"
> selects pages 1 and 2 in a 20 page document.
Hey great, so I would be happy if you too would go for "2-".
Comment 13 Michael Weghorn 2020-11-18 06:52:28 UTC
> (In reply to Michael Weghorn from comment #11)
> > > ... 3) (additional effort, more complexity),
> > Just tested this. It looks like 3 already works, e.g. entering e.g. "-2"
> > selects pages 1 and 2 in a 20 page document.
> Hey great, so I would be happy if you too would go for "2-".

I just tested it and it also works already, so I fully agree we should keep that already existing functionality. :)
Comment 14 sdc.blanco 2020-11-18 08:35:25 UTC
Created attachment 167384 [details]
current draft of proposed help page on print selections

My query (comment 2) that brought this bug report to life was motivated the intention to make a help page about printing selections (see bug 73398 and bug 107192).  Thanks to Michael Weghorn's testing, partial ranges are now added to the planned patch. I have attached a screenshot of the "current draft" for the page. Comments, suggestions, criticisms are welcome.

(and maybe it will help to think about the consequences of design decisions for how to communicate in the documentation.)
Comment 15 Michael Weghorn 2020-11-19 07:19:43 UTC
(In reply to sdc.blanco from comment #14)
> Created attachment 167384 [details]
> current draft of proposed help page on print selections
> 
> My query (comment 2) that brought this bug report to life was motivated the
> intention to make a help page about printing selections (see bug 73398 and
> bug 107192).  Thanks to Michael Weghorn's testing, partial ranges are now
> added to the planned patch. I have attached a screenshot of the "current
> draft" for the page. Comments, suggestions, criticisms are welcome.

Thanks, looks good to me. (Just an "s" is missing in "for a list of page**s**" in section "Printing a range of pages", step 3, third bullet point).
Comment 16 sdc.blanco 2020-11-19 10:50:15 UTC
(In reply to Michael Weghorn from comment #15)
> Thanks, looks good to me. (Just an "s" is missing in "for a list of
> page**s**" in section "Printing a range of pages", step 3, third bullet
> point).
Thanks for feedback (and good proofreading!). Should be online (in corrected version) in a few days:

https://help.libreoffice.org/7.1/en-US/text/swriter/guide/print_selection.html
Comment 17 sdc.blanco 2020-11-19 11:01:01 UTC
Summary of current status (in relation to OP and comment 6)

AFAIK, only two issues remain open for resolving this bug.

1. Should ":" be added as range specifier, in addition to "-"  (mixed opinion)

2. Should "space" be allowed as range specifier  (mostly against)

(NB: At present, "space" does work, so it would be necessary to change the source code to remove this possibility.)