[Libreoffice-bugs] [Bug 122710] PRINT DIALOG: For "Pages to print" field interpret space as separator for a list of distinct pages to print

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri Nov 13 06:49:33 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=122710

--- Comment #7 from Michael Weghorn <m.weghorn at posteo.de> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201113/db6145a9/attachment.htm>


More information about the Libreoffice-bugs mailing list