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:
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
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)
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.
(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... (-:
(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."
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.
(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.
(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.
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.
(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.
(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).
(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-".
> (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. :)
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.)
(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).
(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
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.)
Dear Ulf Zibis, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The documentation part seems solved, see: https://help.libreoffice.org/7.1/en-US/text/swriter/guide/print_selection.html But there are open points from comment 17.
"1 5" actually prints 5 pages: 1 to 5. Preview is correct. Tested with: Version: 7.5.3.2 (x86) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded Version: 7.6.0.1 (x86) / LibreOffice Community Build ID: 776eaf34564cbf3f034a0ba1fd1d5c32ff9ccf1c CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded https://help.libreoffice.org/latest/en-US/text/swriter/guide/print_selection.html Didn't mention the space as page range separator. Other software: Mozilla Firefox don't accept space in the page field (seems good to me). Adobe Reader XI accept space, but this way it prints all pages (from page 1 to the last). Musescore only accept one page number, or two numbers separated with "-", not multiple separated pages or ranges (i.e., 1 or 3-5). Inkscape only accept "," or "-" (i.e., 1,3,5-12). All of them show a warning message.