Print dialogue's height in Libreoffice Writer is too high to see and click buttons.

The height of the new print dialog in version 6.3 is more than 800 pixels high (818 on my Win10). It is reported that real-life systems have smaller height: see https://ask.libreoffice.org/en/question/210159/print-dialog-box-is-to-large-how-to-resize-it/, which mentions 768 pixels of a laptop screen height.

There's a large whitespace in the dialog controls area, so it should allow smaller height.

I made a screenshot of the Print dialog. It's 1212x840 px

many laptops have only 1366x768 px display =(

So => NEW

Created attachment 154607
Screenshot with gtk3 VCL plugin and resolution 800x600

Attached screenshot was taken with gtk3 plugin and laptop screenshot set to 800x600 resolution using master (native resolution: 1920x1080).

For me, the dialog is scrollable, i.e. it seems to be at least usable on screens with lower resolution as well.

I currently don't have Windows at hand to test there.

@Mike: Can you be more explicit about the "large whitespace" you're referring to (e.g. mark that area in a screenshot)?

Created attachment 154608
Print dialog with empty space marked red

I have also tested with 800x600 on Windows, and confirm that it actually is scrollable there.

The attachment shows the area I meant, marked by red rectangle.

Created attachment 154630
screenshot with gtk3 VCL plugin

(In reply to Mike Kaganski from comment #3)
> The attachment shows the area I meant, marked by red rectangle.

Thanks. Is that with the minimum size that the print dialog can have if you resize the window? I don't have that white area on Linux with gtk3, where the dialog opens with its minimum size by default in my case (s. attached screenshot). I do see the white area if I manually enlarge the dialog window, but that seems reasonable to me. (Resolution is 1920x1080)

The new print dialog is really too high as I've vertical and horizontal scrollbars in the 'General' tab on my laptop with 1366x768 (16:9) on Ubuntu Linux 18.04.

indeed, sometimes I have to fiddle around with the heigt

The mockup had a scrollwindow IIRC. And if not, we could introduce that anyway.

(In reply to Heiko Tietze from comment #7)
> The mockup had a scrollwindow IIRC. And if not, we could introduce that
> anyway.

Here we go https://gerrit.libreoffice.org/#/c/80474/

(In reply to Heiko Tietze from comment #8)
> (In reply to Heiko Tietze from comment #7)
> > The mockup had a scrollwindow IIRC. And if not, we could introduce that
> > anyway.
>
> Here we go https://gerrit.libreoffice.org/#/c/80474/

But as noted in comment 2 and comment 3, the dialog *is* scrollable...?

(In reply to Mike Kaganski from comment #9)
> But as noted in comment 2 and comment 3, the dialog *is* scrollable...?

Yes, the tabcontrol has the scrollable property. But I don't see a chance to scroll by default, meaning to not show all control if possible. With a scrollwindow we can make the dialog smaller and scroll the content independently from the screen real estate.

Alternatively, we could use an expander and collapse the page layout. Not sure what's better.

Created attachment 155247
Print dialog update

Range can be more compact cause Even pages and Odd pages is something that is not so often in used. Than you have enough space for the other stuff.

In general it's a bit strange that the dialog didn't use the standard padding settings (6 vertical 12 horizontal).

Created attachment 155248
Dialog with GtkScrollArea

That's how it looks with the patch. Mike's review pending. The alternative is to collapse a section.

(In reply to andreas_k from comment #11)
> Range can be more compact cause Even pages and Odd pages is something...

Looks good with English but I'm afraid of languages that take more space.

(In reply to andreas_k from comment #11)
(In reply to Heiko Tietze from comment #12)

Re: placement of Even/Odd pages: it absolutely doesn't make sense to play with these radiobuttons without considering bug 127680.

Re: comment 8: attachment 155248 shows exactly the same issue with "[] Collate" checkbox which is mentioned in comment 12 wrt Even/Odd (with even more constrained space): it isn't clear that this placement would fit translations.

Created attachment 155249
Print dialog update 02

(In reply to Mike Kaganski from comment #13)
> Re: placement of Even/Odd pages: it absolutely doesn't make sense to play
> with these radiobuttons without considering bug 127680.

with this feedback an drop down menu can be usefull, than you have all pages, even, odd, selection in the drop down menu and the pages selection as second element. So even/odd per selection will work too.

The alignment of vie attechment can be improved. for sure. Now the .ui file use not very common paddings and margins. Ordinary LibO spacing vertical = 6 and spacing horizontal = 12.

(In reply to andreas_k from comment #14)
> with this feedback an drop down menu can be usefull, than you have all
> pages, even, odd, selection in the drop down menu and the pages selection as
> second element. So even/odd per selection will work too.

Note that "All pages"/"Pages"/Selection" is orthogonal from "Even"/"Odd" choices. What you propose now doesn't address the bug 127680 in any way: it would still be impossible to print "Odd pages" from "Selection" or from "pages 100-200 of the 300-page document".

Or put differently: there should be a "range" with choices "All pages of document"/"Pages from manually defined list"/"Current selection", and *independently* another selector is needed, "what to print in the range", with options "All range pages"/"Odd pages"/"Even pages".

(In reply to Mike Kaganski from comment #15)
> Note that "All pages"/"Pages"/Selection" is orthogonal from "Even"/"Odd"
> choices. What you propose now doesn't address the bug 127680 in any way: it
> would still be impossible to print "Odd pages" from "Selection" or from
> "pages 100-200 of the 300-page document".
>
> Or put differently: there should be a "range" with choices "All pages of
> document"/"Pages from manually defined list"/"Current selection", and
> *independently* another selector is needed, "what to print in the range",
> with options "All range pages"/"Odd pages"/"Even pages".

That's not correct as the drop down menu (all pages, even/odd) and pages input field is not linked so you can combine pages selection with even/odd. For sure select and odd/even can't be comined. So an additional checkbutton for print selection would be needed.

And when options come to the More Options button (button next to cancel) can we save than vertical space?

are the settings:

- Order Left to right than down
- Draw a border around each page

usefull when Pages per sheet = 1

can when we show them only if sheet > 1 than we have less widgets at the default print dialog.

Stepping back from implementation, my take is in comment 10.

Created attachment 155585
Print dialog update 03

Size is now 861 x 673 px (which is larger than 800 x 600 px written is defined in the guidelines as maximum dialog size.

anyway it's way better than now. Save is around 100 px in width and height.

Arrangement:
------------
one columns for labels and one column for widgets. maximum width depend on the maximum label and widget size. In English the width is defined from:
- Number of copies (can be reduced to Copies:)
- Page size widget cause there are some special Labels called #8 (Monaarch) Envelope 98mm x 191 mm)

Difference to master:
---------------------
- Page Range is an drop down menu instead of radioboxes (like in MSO)
- Brochure radio button was removed (I don't know what's Brochure) I think it can be integrated int Pages per sheet drop down menu.

Save additional space:
----------------------
If we want to get the 800 x 600 px there are the following options:
- Remove Left to right, the down widget
- Remove Draw a border around each page checkbox, cause this two settings are not needed when Page per sheet = 1 (default behavior)
- Make Preview area smaller
- Reduce label length
- Reduce widget label length

We have goal to decrease print range from 5 to 3 rows.
I wouldn't like to go back from what was changed in Bug 122707. Meaning that I don't like "range" dropdown.
Could we have radio or check:
All pages Selection (radio)
Odd Even (radio)
Pages: (smaller box) Reverse order (check)

*** Bug 128869 has been marked as a duplicate of this bug. ***

Created attachment 155933
Print dialog update 04

Thanks for the feedback.

I made an patch with the existing elements (radiobuttons, ...)

https://gerrit.libreoffice.org/#/c/83137/

As I have an 1366x768px laptop display I could test the patch myself.

What does the patch fix:
+ default size fit's into 768px height
+ spacing is 3px in height and follow HIG
+ There is no additional space between Pages per sheet and Order
+ If you scale the dialog only the preview change width (General tab has always the same width) ! I think this is very usefull !
- I removed the Order label next to Print in reverse order checkbox (cause it's not needed as explanation)
- I moved the Page per sheet preview to the left (next to the radio button), cause otherwise there is this additional space between 1 and Left to right, than down.

I can remove the two - items if wanted.

The last print dialog is very nice and compact.

Created attachment 155953
Print dialog update 05

Ok next iteration on the left. I would recommend to hide the Collate preview if copies = 1 and if nothing is selected than hide the selection radio box (which reduce the dialog widget number number and the height.

But for this I need someone how code it. However I think the dialog is not an complete redesign but definitely an improvement.

Hi Andreas,
Please take into account that Caolán recently submitted a commit for a related issue ( bug 128495 ) -> https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-3&id=4cf00f070fa5771bf5e6382cffe933beb65ca4b8

Created attachment 156079
On macOS 10.14.6

*** Bug 129379 has been marked as a duplicate of this bug. ***

https://lists.freedesktop.org/archives/libreoffice/2019-December/084100.html

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ab6b0514c767ea3e5f1802b6f99412d1e726b2e1

Related: tdf#127782 call signal_expanded after expansion in gtk case

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

*** Bug 129860 has been marked as a duplicate of this bug. ***

Created attachment 157131
Print dialog update 06

Mix Between Print dialog update 02 - 05

The Range is defined via drop down menu and with Pages you can select specific pages. This has the following benefits:
+ Selection can be predefined as default if the user has something selected and if not Selected is not available in the drop down menu
+ Even Odd Pages can be combined with Print n to m (see comment 13)
+ Page height is less than 768 px
+ All Options was shown nothing is hidden
+ Grouping and alignment of the drop down menu
+ Range can be extended cause it's an drop down menu (with current page for example)

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/96b4bf352b1dc43637080719c91eef61fef74bf8

Resolves tdf#127782 - New Print dialog is too high

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fa412876add97cab38d404723c49d35775f8efea

Related: tdf#127782 resize the print dialog to its optimum size...

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Commit Notification from comment #33)
> 96b4bf352b1dc43637080719c91eef61fef74bf8

This patch places content of the dialog in collapsed expanders so we have a solution for users with small screens. My reasoning was:
* Print range (with all and a defined range) is the most relevant choice
* Keep the list of radio buttons tied
* Page dimension (A4) and orientation (portrait/landscape) are used to verify the printout
* Number of copies is not always used
* Pages per sheet etc. is advanced stuff

(In reply to Commit Notification from comment #34)
> fa412876add97cab38d404723c49d35775f8efea

Caolan's patch makes sure that expanding/collapsing sections trigger the dialog resizing.

Confirming also o,

Confirming with

Version: 6.3.4.2
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
Threads CPU : 4; OS : Mac OS X 10.15.2; UI Render : par défaut; VCL: osx;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

MacMini : 10.15.2
Output Display : 1920 x 1080

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0874fa237b3b6be3890915a744c5d34ba2bef8f7

Related: tdf#127782 use size groups to avoid changing widths on using expanders

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/06f761fe43b184fb0b8306967e55da61d2b1ca1b

Related: tdf#127782 call signal_expanded after expansion in gtk case

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Heiko Tietze from comment #96)
> (In reply to Commit Notification from comment #95)
> > Heiko Tietze committed a patch related to this issue.
>
> This patch adds a scroll window behind the properties so the tab has a
> defined height of 500px (+ some for the controls around) and scrolls the
> remaining content. Please try on different plattforms, Windows and macOS
> with small screens. I can still backport to 6.4. Hard code freeze is next
> week.

I tested master~2020-04-24_20.27.57_LibreOfficeDev_7.0.0.0.alpha0_Linux_x86-64_deb.tar.gz under Ubuntu 20.04 (GNOME/Adwaita Theme):

At least the buttons are now always visible. But the behavior is a bit strange. First, the print dialog looks like attachment 159920

Please not that the gui elements do not fit horizontally (see e.g. the Properties button on the right)

When I click on "more", the field gets expanded but the overall height of the print dialog decreases. See attachment 159922

*** Bug 132407 has been marked as a duplicate of this bug. ***

Created attachment 159946
Issue at screen resolution 1366×768 and VCL gtk3

I can confirm this issue with Libreoffice 6.4.3.2 (Build ID: 6.4.3-1), Manjaro XFCE Linux
Interface: VCL: gtk3;
Locale used is: it-IT as is the interface language

Screen resolution is 1366 × 768 pixels

Attached is a 1:1 screenshot.

(In reply to FerbTux from comment #99)
> At least the buttons are now always visible. But the behavior is a bit
> strange.

Missed to set an attribute. The dialog is now optimal scaled on the horizontal axis and has a pre-defined height with a vertical scrollbar that should fit all screen sizes. Pushing to 6.4 now, thanks for testing.

Created attachment 160040
PrintDialog LibreOffice 7.0 daily build 20200427 (Gnome/Adwaita theme)

I tested master~2020-04-27_02.01.12_LibreOfficeDev_7.0.0.0.alpha0_Linux_x86-64_deb.tar.gz

Now it's almost perfect. Nothing is cropped on the right and the dialog keeps its height.
Only a minor nuisance is left: The second more button is a little bit cropped (see screenshot)

*** Bug 132794 has been marked as a duplicate of this bug. ***

With

Version : 6.4.3.2
Build ID : 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
Threads CPU : 8; OS : Mac OS X 10.15.4; UI Render : par défaut; VCL: osx;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

on MacBook Pro (Retina, 15 inch, end 2013), 2880 x 1800 the dialog fits (just) within the boundaries of the spare screen real estate.

Testing on a macMini with an output resolution of 1366x768 with the same LO version shows that the problem is _not_ resolved. The dialog in this instance still overlaps the available screen real estate.

(In reply to Alex Thurgood from comment #105)
> Version : 6.4.3.2

Please test with a nightly build (or RC1) of 7.0.

*** Bug 133060 has been marked as a duplicate of this bug. ***

*** Bug 133973 has been marked as a duplicate of this bug. ***

I confirm, that on the Dell Latitude E7250 with Debian Sid/unstable with GNOME 3.36.3 and LibreOffice 1:7.0.0~rc1-5, the issue is fixed.

There is a small glitch though, and I created bug #134679.

[1]: https://bugs.documentfoundation.org/show_bug.cgi?id=134679

(In reply to Heiko Tietze from comment #106)
> (In reply to Alex Thurgood from comment #105)
> > Version : 6.4.3.2
>
> Please test with a nightly build (or RC1) of 7.0.

Still not fixed with

Version: 7.1.0.0.alpha0+
Build ID: <buildversion>
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

and also reported separately in bug 136609

Reopening.

(In reply to Alex Thurgood from comment #110)
> (In reply to Heiko Tietze from comment #106)
> > (In reply to Alex Thurgood from comment #105)
> > > Version : 6.4.3.2
> >
> > Please test with a nightly build (or RC1) of 7.0.
>
> Still not fixed with
>
> Version: 7.1.0.0.alpha0+
> Build ID: <buildversion>
> CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); UI: en-US
> Calc: threaded
>
> and also reported separately in bug 136609
>
> Reopening.

Note that LibreOffice Vanilla appears to diplay the dialog correctly, whereas LO7001rc and my test on 7100alpha, do not display the dialog correctly.

*** Bug 136609 has been marked as a duplicate of this bug. ***

(In reply to Alex Thurgood from comment #111)

>
> Note that LibreOffice Vanilla appears to diplay the dialog correctly,
> whereas LO7001rc and my test on 7100alpha, do not display the dialog
> correctly.

Also tested on
Version: 6.4.6.2
Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx;
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded

problem reproducible there too.

Reproduced also with

Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

Created attachment 165471
Screenshot of LO 7.0.1.2 Print Dialog macOS 10.15.6

*** Bug 136305 has been marked as a duplicate of this bug. ***

(In reply to Alex Thurgood from comment #115)
> Screenshot of LO 7.0.1.2 Print Dialog macOS 10.15.6

Print dialog was changed by Olivier Hallot for bug 118148, Srijan Bhatia for bug 127680, andreas kainz bug 128723, and Caolan did something in Ib855c429ac936f9b7bb219ad4729f99b0625ec37. The dialog looks different on my machine when build from sources. => Topic for QA

(In reply to Heiko Tietze from comment #117)
> (In reply to Alex Thurgood from comment #115)
> > Screenshot of LO 7.0.1.2 Print Dialog macOS 10.15.6
>
> Print dialog was changed by Olivier Hallot for bug 118148, Srijan Bhatia for
> bug 127680, andreas kainz bug 128723, and Caolan did something in
> Ib855c429ac936f9b7bb219ad4729f99b0625ec37. The dialog looks different on my
> machine when build from sources. => Topic for QA

What do you mean ? if it's a new regression, it should be reported in a new ticket.

*** Bug 137142 has been marked as a duplicate of this bug. ***

I would just like to record that the recent Ubuntu mutter fix referenced here
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1892440
has NOT fixed the Libre Office Print Dialogue box problem.

20201122 This problem has reduced LibreOffice to a non working program for me, Laptop Dell 15.5 screen Dialog is unusable in XFCE openSUSE LEAP 15.2.gice to pupils
After many years of promoting Libreoffice to seniors, I teach, I can no longer do so with confidence.

Created attachment 167483
Print dialog button commands are off screen

dialog of unusable print pop up in LibreOffice

(In reply to Eion MacDonald from comment #122)
> dialog of unusable print pop up in LibreOffice

Workaround might be to maximize the window. But please try a nightly build first. IIRC the issue has been solved with another patch recently.

For me the nightly build does not work either.
I am running LibreOffice Version: 6.4.6.2
Build ID: 1:6.4.6-0ubuntu0.20.04.1
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3;
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

on aLenovo t410 laptop runnng fully updated/upgraded Ubuntu 20.04 LTS.

I have accessibility Large Text switched on, which IMHO is something to do with the problem. If I switch Large Text off, the OK button and others are available at the bottom of the screen BUT all menu text etc is very small causing me to squint.

I agree with others, the failure to fix this bug for many months is damaging LibreOffice reputation.

(In reply to Heiko Tietze from comment #123)
> (In reply to Eion MacDonald from comment #122)
> > dialog of unusable print pop up in LibreOffice
>
> Workaround might be to maximize the window. But please try a nightly build
> first. IIRC the issue has been solved with another patch recently.

I have tried to maximize the print dialog, it does not work, vertical height remains the same.
Maximizing the whole screen, and removing tool bars , does not work.
As I operate a stable build from repros openSUSE LEAP 15.2 on this production machine, I do not try nightly builds. Thanks for hint.

The last patch stores the state of the "More" expanders and should remember the window size (might not work for some reason).

I suggest to create new tickets if something needs fine-tuning.

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/149807eb6100090e178505ba4a264bb38eba1e0c

Resolves tdf#127782 - Print dialog height

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

*** Bug 141536 has been marked as a duplicate of this bug. ***

Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/252bdaaf85466cc97cbd9e79390e24b68bc3ecb6

Resolves tdf#127782 - Print dialog height

It will be available in 7.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.