Download it now!
Bug 127782 - New Print dialog is too high
Summary: New Print dialog is too high
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.2.2 release
Hardware: All All
: medium normal
Assignee: Heiko Tietze
URL:
Whiteboard: target:6.5.0 target:6.4.1 target:7.0....
Keywords:
: 128869 129379 129860 130667 130747 130903 131119 131139 131429 131689 131741 132407 132794 133060 133973 (view as bug list)
Depends on:
Blocks: Print-Dialog
  Show dependency treegraph
 
Reported: 2019-09-26 10:50 UTC by Mike Kaganski
Modified: 2020-07-09 07:49 UTC (History)
32 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot with gtk3 VCL plugin and resolution 800x600 (50.91 KB, image/png)
2019-09-27 20:22 UTC, Michael Weghorn
Details
Print dialog with empty space marked red (16.26 KB, image/png)
2019-09-27 21:34 UTC, Mike Kaganski
Details
screenshot with gtk3 VCL plugin (57.08 KB, image/png)
2019-09-29 02:42 UTC, Michael Weghorn
Details
Print dialog update (132.91 KB, image/png)
2019-10-22 22:43 UTC, andreas_k
Details
Dialog with GtkScrollArea (183.72 KB, image/png)
2019-10-23 07:21 UTC, Heiko Tietze
Details
Print dialog update 02 (132.45 KB, image/png)
2019-10-23 08:24 UTC, andreas_k
Details
Print dialog update 03 (247.38 KB, image/png)
2019-11-06 17:06 UTC, andreas_k
Details
Print dialog update 04 (82.37 KB, image/png)
2019-11-18 23:14 UTC, andreas_k
Details
Print dialog update 05 (111.66 KB, image/png)
2019-11-19 23:31 UTC, andreas_k
Details
On macOS 10.14.6 (82.93 KB, image/png)
2019-11-24 20:42 UTC, Samuel Bächler
Details
Print dialog update 06 (110.77 KB, image/png)
2020-01-13 19:59 UTC, andreas_k
Details
Print Dialog too large and buttons blocked by Taskbar (74.81 KB, image/png)
2020-02-01 01:27 UTC, Bud
Details
PrintDialog with LibreOffice 6.4.2.2 under Gnome (Ubuntu) (101.14 KB, image/png)
2020-03-29 10:32 UTC, FerbTux
Details
Failing dialog size (212.05 KB, image/png)
2020-03-30 12:05 UTC, kevin
Details
working dialog (181.04 KB, image/png)
2020-03-30 12:07 UTC, kevin
Details
French print dialog (91.19 KB, image/png)
2020-04-08 07:34 UTC, Michel
Details
Screenshot showing the new expander sections (47.25 KB, image/png)
2020-04-08 07:41 UTC, Heiko Tietze
Details
LO 6.4.4's print dialog fits OK inside my 1366x768 screen (89.31 KB, image/png)
2020-04-15 20:24 UTC, Carlos Pasqualini
Details
1280x720px Gnome3 (85.78 KB, image/png)
2020-04-15 20:45 UTC, Carlos Pasqualini
Details
Fits OK on 1024x768px Gnome3 (75.18 KB, image/png)
2020-04-15 20:46 UTC, Carlos Pasqualini
Details
Does NOT fit on a 960x720px (53.80 KB, image/png)
2020-04-15 20:50 UTC, Carlos Pasqualini
Details
PrintDialog LibreOffice 7.0 daily build (Gnome/Adwaita theme) (85.79 KB, image/png)
2020-04-25 14:08 UTC, FerbTux
Details
PrintDialog more clicked LibreOffice 7.0 daily build (Gnome/Adwaita theme) (103.93 KB, image/png)
2020-04-25 14:09 UTC, FerbTux
Details
Issue at screen resolution 1366×768 and VCL gtk3 (90.02 KB, image/png)
2020-04-26 09:06 UTC, lorenzosu
Details
PrintDialog LibreOffice 7.0 daily build 20200427 (Gnome/Adwaita theme) (91.69 KB, image/png)
2020-04-28 19:28 UTC, FerbTux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-09-26 10:50:45 UTC
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.
Comment 1 Roman Kuznetsov 2019-09-26 13:28:23 UTC
I made a screenshot of the Print dialog. It's 1212x840 px

many laptops have only 1366x768 px display =(

So => NEW
Comment 2 Michael Weghorn 2019-09-27 20:22:11 UTC
Created attachment 154607 [details]
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)?
Comment 3 Mike Kaganski 2019-09-27 21:34:33 UTC
Created attachment 154608 [details]
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.
Comment 4 Michael Weghorn 2019-09-29 02:42:08 UTC
Created attachment 154630 [details]
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)
Comment 5 Thomas Lendo 2019-10-02 20:27:58 UTC
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.
Comment 6 Cor Nouws 2019-10-03 12:08:06 UTC
indeed, sometimes I have to fiddle around with the heigt
Comment 7 Heiko Tietze 2019-10-05 08:14:32 UTC
The mockup had a scrollwindow IIRC. And if not, we could introduce that anyway.
Comment 8 Heiko Tietze 2019-10-08 14:29:59 UTC
(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/
Comment 9 Mike Kaganski 2019-10-08 14:42:34 UTC
(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...?
Comment 10 Heiko Tietze 2019-10-09 08:31:32 UTC
(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.
Comment 11 andreas_k 2019-10-22 22:43:36 UTC
Created attachment 155247 [details]
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).
Comment 12 Heiko Tietze 2019-10-23 07:21:17 UTC
Created attachment 155248 [details]
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.
Comment 13 Mike Kaganski 2019-10-23 07:41:11 UTC
(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 [details] 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.
Comment 14 andreas_k 2019-10-23 08:24:05 UTC
Created attachment 155249 [details]
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.
Comment 15 Mike Kaganski 2019-10-23 08:42:30 UTC
(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".
Comment 16 andreas_k 2019-10-23 08:57:56 UTC
(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.
Comment 17 andreas_k 2019-11-06 08:26:03 UTC
And when options come to the More Options button (button next to cancel) can we save than vertical space?
Comment 18 andreas_k 2019-11-06 08:28:08 UTC
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.
Comment 19 Heiko Tietze 2019-11-06 09:52:03 UTC
Stepping back from implementation, my take is in comment 10.
Comment 20 andreas_k 2019-11-06 17:06:52 UTC
Created attachment 155585 [details]
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
Comment 21 Timur 2019-11-14 18:30:42 UTC
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)
Comment 22 Timur 2019-11-18 20:50:33 UTC
*** Bug 128869 has been marked as a duplicate of this bug. ***
Comment 23 andreas_k 2019-11-18 23:14:12 UTC
Created attachment 155933 [details]
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.
Comment 24 BogdanB 2019-11-19 06:04:19 UTC
The last print dialog is very nice and compact.
Comment 25 andreas_k 2019-11-19 23:31:32 UTC
Created attachment 155953 [details]
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.
Comment 26 Xisco Faulí 2019-11-20 09:58:42 UTC
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
Comment 27 Samuel Bächler 2019-11-24 20:42:20 UTC
Created attachment 156079 [details]
On macOS 10.14.6
Comment 28 So 2019-12-14 01:34:48 UTC
*** Bug 129379 has been marked as a duplicate of this bug. ***
Comment 30 Commit Notification 2020-01-10 19:36:19 UTC
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.
Comment 31 steve -_- 2020-01-13 09:30:23 UTC
*** Bug 129860 has been marked as a duplicate of this bug. ***
Comment 32 andreas_k 2020-01-13 19:59:16 UTC
Created attachment 157131 [details]
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)
Comment 33 Commit Notification 2020-01-14 08:44:10 UTC
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.
Comment 34 Commit Notification 2020-01-14 08:44:20 UTC
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.
Comment 35 Heiko Tietze 2020-01-14 08:52:57 UTC
(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.
Comment 36 Alex Thurgood 2020-01-14 09:15:11 UTC
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
Comment 37 Commit Notification 2020-01-16 14:22:37 UTC
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.
Comment 38 Commit Notification 2020-01-18 21:04:35 UTC
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.
Comment 39 Bud 2020-02-01 01:27:05 UTC
Created attachment 157574 [details]
Print Dialog too large and buttons blocked by Taskbar
Comment 40 andreas_k 2020-02-13 22:12:33 UTC
(In reply to Bud from comment #39)
> Created attachment 157574 [details]
> Print Dialog too large and buttons blocked by Taskbar

can confirm only at the qt backend it work.
Comment 41 Mike Kaganski 2020-02-18 06:04:58 UTC
See also: https://ask.libreoffice.org/en/question/227762 (with screenshot from 6.4.1.1)
Comment 42 Dieter 2020-02-18 08:11:48 UTC
*** Bug 130747 has been marked as a duplicate of this bug. ***
Comment 43 Oliver Brinzing 2020-02-24 18:17:45 UTC
*** Bug 130903 has been marked as a duplicate of this bug. ***
Comment 44 Heiko Tietze 2020-02-25 15:24:42 UTC
Should be solved now. Xisco: backport to 6.4?
Comment 45 Commit Notification 2020-02-25 15:25:30 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

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

Resolves tdf#127782 - New Print dialog is too high

It will be available in 7.0.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.
Comment 46 Xisco Faulí 2020-02-25 15:57:38 UTC
(In reply to Heiko Tietze from comment #44)
> Should be solved now. Xisco: backport to 6.4?

sure!
Comment 47 Matthias Hellinghausen 2020-03-04 13:37:33 UTC
(In reply to Heiko Tietze from comment #44)
> Should be solved now. Xisco: backport to 6.4?

would be highly appreciated!
Comment 48 Xisco Faulí 2020-03-04 17:12:16 UTC
*** Bug 131119 has been marked as a duplicate of this bug. ***
Comment 49 Commit Notification 2020-03-04 20:18:59 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/9c3171d4209f8eceb0152d7d9f70456c5813914e

Resolves tdf#127782 - New Print dialog is too high

It will be available in 6.4.3.

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.
Comment 50 Ming Hua 2020-03-05 03:06:55 UTC
*** Bug 131139 has been marked as a duplicate of this bug. ***
Comment 51 Dieter 2020-03-05 17:48:10 UTC Comment hidden (obsolete)
Comment 52 Bud 2020-03-08 14:39:05 UTC
Using the Win-x86_64@tb77-TDF-nomerge 2020-03-08 05:06:43 build, I am finding that the Print Dialog Box is well within the height parameters.  So, this will fix the problem for me.  FYI, I am using Custom Scaling Size of 125.
Comment 53 Commit Notification 2020-03-11 09:29:11 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-2":

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

Resolves tdf#127782 - New Print dialog is too high

It will be available in 6.4.2.

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.
Comment 54 NISZ LibreOffice Team 2020-03-20 08:24:56 UTC
*** Bug 131429 has been marked as a duplicate of this bug. ***
Comment 55 Bud 2020-03-20 20:17:34 UTC
Problem has been fixed for me as of Version: 6.4.2.2
Comment 56 rezso 2020-03-23 14:54:04 UTC
6.4.2.2 release not solved the problem for me, so I reduced the constants to 35 and 20, but the print dialog too high now too.
Comment 57 Timur 2020-03-23 16:33:19 UTC
*** Bug 130667 has been marked as a duplicate of this bug. ***
Comment 58 rezso 2020-03-23 21:03:08 UTC
I have 1366 x 768 screen resolution. Mate desktop, with top and bottom panels - and the print dialog is too high.
Comment 59 Timur 2020-03-24 06:34:25 UTC
@rezso: Print dialog is well within 1366 x 768 screen resolution.
So I don't think that should and will be changed for some specific situations as yours. In this bug unlikely and in some other also not probable.
But let's first see it, please make a screenshot.
Comment 60 FerbTux 2020-03-27 11:56:15 UTC
The issue still occurs if the gtk(3) backend is used:

E.g. with Gnome3 as desktop, the print dialog is too high. But if libreoffice is started with

SAL_USE_VCLPLUGIN=gen libreoffice

the native user inferface is used and the print dialog fits into the screen.
(Tested with Gnome 3.36, LibreOffice 6.4.2.2, 1366x768)
Comment 61 FerbTux 2020-03-29 10:32:55 UTC
Created attachment 159114 [details]
PrintDialog with LibreOffice 6.4.2.2 under Gnome (Ubuntu)

This screenshot shows the print dialog with LibreOffice 6.4.2.2 (flatpak) under Gnome (Ubuntu 19.10) with a resolution of 1360x768.
It can be seen, that the buttons (cancel/ok) at the lower end of the dialog are not visible. This makes it almost impossible to print (the buttons can be selected with the TAB key).
Comment 62 So 2020-03-30 05:45:51 UTC
*** Bug 131689 has been marked as a duplicate of this bug. ***
Comment 63 kevin 2020-03-30 12:05:24 UTC
Created attachment 159145 [details]
Failing dialog size
Comment 64 kevin 2020-03-30 12:07:06 UTC
Encountered this on 1.6.4 today.

I have a ThinkPad X260 with a 1366x768 display

I could not reach the booklet printing option when first opening the dialog. In fact it seems like the option does not exist! I tried all sorts of resizing but no improvement. (Screenshot kpc 1)

When I connected a second screen I could use the dialog as the screen was taller (!) (Screenshot kpc 2)

Dialog requires internal scrollbars so no option is lost on smaller screens.

1.6.4 on KDE Neon
Comment 65 kevin 2020-03-30 12:07:52 UTC
Created attachment 159146 [details]
working dialog
Comment 66 Xisco Faulí 2020-03-31 14:07:13 UTC
*** Bug 131741 has been marked as a duplicate of this bug. ***
Comment 67 FerbTux 2020-04-03 18:20:58 UTC
Workaround to make the buttons visible with GNOME (Tested with GNOME 3.34 and 3.36):

It is possible to make the buttons visible by moving up the print dialog.
First, the attachment of modal dialogs must be disabled (note: the setting disables it globally for all applications!)

In a Terminal:
gsettings set org.gnome.mutter attach-modal-dialogs false

Alternative:
Use gnome-tweaks: Windows -> Attach Modal Dialogs = off

When now the print dialog is shown, the movement can be activated with ALT+F7. Use the UP key afterwards to move the window upwards until the buttons are visible. Confirm with ENTER key.

If an overlay/window action key is set (gnome-tweaks: Windows -> Window Action Key) the window can also be moved by holding the specified key and dragging the window to the desired position)
Comment 68 Heiko Tietze 2020-04-08 06:37:48 UTC
The issue has been solved in version 7.0, 6.5, and 6.4.1.
Comment 69 Paul Menzel 2020-04-08 07:03:58 UTC
(In reply to Heiko Tietze from comment #68)
> The issue has been solved in version 7.0, 6.5, and 6.4.1.

No, as commented above it’s still present in 6.4.2.2.
Comment 70 Michel 2020-04-08 07:31:31 UTC
On Mac os, french print dialog is still too high because of two-lines translation (
Comment 71 Michel 2020-04-08 07:34:42 UTC
Created attachment 159415 [details]
French print dialog
Comment 72 Heiko Tietze 2020-04-08 07:41:41 UTC
Created attachment 159417 [details]
Screenshot showing the new expander sections

The patch introduced expanders (see ">more") to hide parts of the dialog. It's ~600px high on my system with gtk3. 

@Xisco: I wonder why it's not available in 6.4.2 since the patch was backported.
Comment 73 Xisco Faulí 2020-04-08 08:00:16 UTC Comment hidden (off-topic)
Comment 74 Heiko Tietze 2020-04-08 08:01:17 UTC Comment hidden (off-topic)
Comment 75 Heiko Tietze 2020-04-08 09:44:46 UTC
My fault, ui patch was done independently and hasn't been backported. On it's way now...
Comment 76 Commit Notification 2020-04-08 11:10:05 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

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

Resolves tdf#127782 - New Print dialog is too high

It will be available in 6.4.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.
Comment 77 Rene Engelhard 2020-04-13 09:44:41 UTC
There is now an expander. The dialog itself will be
bigger than the screen when expanded, but that easily can be unexpanded.

So it moved from a problem to just a minor nuisance :)
Comment 78 Heiko Tietze 2020-04-14 09:56:28 UTC
According comment 9 it shouldn't be a nuisance. Please resolve when done.
Comment 79 Rene Engelhard 2020-04-15 06:44:29 UTC
but it is.

No, there's nothing scrollable to reach OK. But even if it was, this would be a nuisance.
Comment 80 Heiko Tietze 2020-04-15 15:43:54 UTC
(In reply to Rene Engelhard from comment #79)
> No, there's nothing scrollable to reach OK. But even if it was, this would
> be a nuisance.

Maximize the dialog on small screens and the GtkScrollArea becomes active. Scrolling per se is not a bad idea, though admittedly it should be a matter of fact when the dialog shows up. Would handle this issue in another ticket.
Comment 81 Carlos Pasqualini 2020-04-15 20:24:29 UTC
Created attachment 159594 [details]
LO 6.4.4's print dialog fits OK inside my 1366x768 screen
Comment 82 Carlos Pasqualini 2020-04-15 20:31:44 UTC
I'm testing the packages provided by Rene Engelhard (thanks!) on a Debian testing with 1366x768 screen

Versión: 6.4.4.0.0+
Id. de compilación: 1:6.4.4~rc1~git20200412-1
Subprocs. CPU: 4; SO: Linux 5.5; Repres. IU: predet.; VCL: gtk3; 
Configuración regional: es-AR (es_AR.UTF-8); Idioma de IU: es-ES
Calc: threaded

It seems to work as expected, you can see my previous attachment 

Thanks
Comment 83 Carlos Pasqualini 2020-04-15 20:45:16 UTC
Created attachment 159596 [details]
1280x720px Gnome3

It fit's on a 1280x720 screen
Comment 84 Carlos Pasqualini 2020-04-15 20:46:40 UTC
Created attachment 159597 [details]
Fits OK on 1024x768px Gnome3
Comment 85 Carlos Pasqualini 2020-04-15 20:50:10 UTC
Created attachment 159598 [details]
Does NOT fit on a 960x720px
Comment 86 Carlos Pasqualini 2020-04-15 20:53:24 UTC
(In reply to Heiko Tietze from comment #80)
> (In reply to Rene Engelhard from comment #79)
> > No, there's nothing scrollable to reach OK. But even if it was, this would
> > be a nuisance.
> 
> Maximize the dialog on small screens and the GtkScrollArea becomes active.
> Scrolling per se is not a bad idea, though admittedly it should be a matter
> of fact when the dialog shows up. Would handle this issue in another ticket.

Heiko

I had not find any scroll area you mention on the tests I've made, when the dialog doesn't fit inside the screen, the accept and cancel buttons where not clickable at all. I hope you can see it yourself on the provided screenshots

Thanks!
Comment 87 Rene Engelhard 2020-04-15 21:32:01 UTC
No, it does not.

The window is not resizable and not scrollable even when the expanders are open.

At least here.

See http://www.rene-engelhard.de/~rene/libreoffice/tdf127782.webm
Comment 88 Carlos Pasqualini 2020-04-15 21:52:42 UTC
Yes Rene

In your provided video we can see what i was trying to explain to Heiko, even with LO 7

Thanks!
Comment 89 Paul Menzel 2020-04-17 05:59:45 UTC
Just for the record, as expected this still happens in 6.4.3, which was just uploaded to Debian Sid/unstable. As comment 76 points out, the fix will be in version 6.4.4.

Also, the meta data *Version* field says to use the earliest affected version. Should it be changed to 6.3?
Comment 90 Heiko Tietze 2020-04-20 13:35:58 UTC
(In reply to Rene Engelhard from comment #79)
> No, there's nothing scrollable to reach OK. But even if it was, this would
> be a nuisance.

I also struggled with Mike's comment 3. The scroll bars show up when you maximize the dialog on a small screen. Of course it would be better when the dialog is scrollable from the beginning, different issue.

Nuisance is minor to me this is the most common interaction in browsers. Consider also the alternative where we have to split the options onto different tabs. For my taste this is the less usable solution.

(In reply to Carlos Pasqualini from comment #85)
> Does NOT fit on a 960x720px

Thanks for testing. Minimal requirement for LibreOffice is 1024x768px. Wouldn't want to write a novel even on this screen size ;-).
Comment 91 glentrobfc 2020-04-20 18:51:08 UTC
My Macbook Air 11 inch mid-2012 has a display resolution 1366 x 768 and with macOS Catalina there is no way to resize or move the window up.  The end result there is no way to print from writer.  Cancel is not viewable, but the dialogue can be exited with escape
Comment 92 FerbTux 2020-04-21 10:52:13 UTC
(In reply to glentrobfc from comment #91)
> My Macbook Air 11 inch mid-2012 has a display resolution 1366 x 768 and with
> macOS Catalina there is no way to resize or move the window up.  The end
> result there is no way to print from writer.  Cancel is not viewable, but
> the dialogue can be exited with escape

It might also possible to use the native dialogs on MacOS (see my comment 60). LibreOffice looks a bit outdated, but the print dialog is much smaller and fits into the screen.
To use the native dialogs, the environment variable SAL_USE_VCLPLUGIN must be set to "gen"
SAL_USE_VCLPLUGIN=gen
Comment 93 FerbTux 2020-04-21 10:57:50 UTC
I've tested libreoffice-6-4~2020-04-16_19.54.12_LibreOfficeDev_6.4.4.0.0_Linux_x86-64_deb.tar.gz on Ubuntu 20.04 with gnome-session (vanilla GNOME with Adwaita theme):
By default, when both expanders are not expanded, the buttons are visible. But if both expanders are expanded, the buttons are no longer accessible.
No scroll area appears. I think there is no way to maximize the dialog.
Comment 94 Carlos Pasqualini 2020-04-21 14:23:45 UTC
(In reply to FerbTux from comment #93)
> I've tested
> libreoffice-6-4~2020-04-16_19.54.12_LibreOfficeDev_6.4.4.0.0_Linux_x86-
> 64_deb.tar.gz on Ubuntu 20.04 with gnome-session (vanilla GNOME with Adwaita
> theme):
> By default, when both expanders are not expanded, the buttons are visible.
> But if both expanders are expanded, the buttons are no longer accessible.
> No scroll area appears. I think there is no way to maximize the dialog.

Yes FerbTux

What you describe about Gnome is exactly what Rene (comment 87) and me (since comment 81) where talking about Libreoffice and GTK3.

There is no scroll when both are expanded, but it is (at least) usable, and this is far better than the status reported in 6.2.2 and the actual status in Debian Testing with 6.4.3.


I suggest to keep in mind distribution's versions, like Ubuntu and derivatives:
https://packages.ubuntu.com/search?keywords=libreoffice

Does Ubuntu 19.04 and 19.10 official packages has these issues?

I think this status should be backported soon to older affected versions, as there are Distribution's users that are not able to print right now, and the wait for at least 6.4.4 will be longer than if these changes can be backported and get distribution's updates.

As far as I know, Debian is affected in Stable-Backports, Testing and Unstable only, which should soon get 6.4.4, correct me if I am wrong Rene

Did not check other main distributions, like SuSE or Fedora


Best regards
Comment 95 Commit Notification 2020-04-23 18:14:41 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/26ada4335a5804735ae37cf9a89f8145e0931fd7

tdf#127782 - New Print dialog is too high

It will be available in 7.0.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.
Comment 96 Heiko Tietze 2020-04-23 18:19:19 UTC
(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.
Comment 97 FerbTux 2020-04-25 14:08:41 UTC
Created attachment 159920 [details]
PrintDialog LibreOffice 7.0 daily build (Gnome/Adwaita theme)
Comment 98 FerbTux 2020-04-25 14:09:42 UTC
Created attachment 159922 [details]
PrintDialog more clicked LibreOffice 7.0 daily build (Gnome/Adwaita theme)
Comment 99 FerbTux 2020-04-25 14:15:57 UTC
(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 [details]

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 [details]
Comment 100 Timur 2020-04-25 18:15:03 UTC
*** Bug 132407 has been marked as a duplicate of this bug. ***
Comment 101 lorenzosu 2020-04-26 09:06:08 UTC
Created attachment 159946 [details]
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.
Comment 102 Heiko Tietze 2020-04-27 11:27:30 UTC
(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.
Comment 103 FerbTux 2020-04-28 19:28:32 UTC
Created attachment 160040 [details]
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)
Comment 104 Ming Hua 2020-05-07 01:46:50 UTC
*** Bug 132794 has been marked as a duplicate of this bug. ***
Comment 105 Alex Thurgood 2020-05-07 08:36:33 UTC
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.
Comment 106 Heiko Tietze 2020-05-07 09:25:17 UTC
(In reply to Alex Thurgood from comment #105)
> Version : 6.4.3.2

Please test with a nightly build (or RC1) of 7.0.
Comment 107 Ming Hua 2020-05-16 03:20:14 UTC
*** Bug 133060 has been marked as a duplicate of this bug. ***
Comment 108 m.a.riosv 2020-06-14 14:33:21 UTC
*** Bug 133973 has been marked as a duplicate of this bug. ***
Comment 109 Paul Menzel 2020-07-09 07:49:39 UTC
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