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 [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)?
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.
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)
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 [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).
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.
(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.
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.
(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 [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
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 [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.
The last print dialog is very nice and compact.
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.
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 [details] 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 [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)
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.
Created attachment 157574 [details] Print Dialog too large and buttons blocked by Taskbar
(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.
See also: https://ask.libreoffice.org/en/question/227762 (with screenshot from 6.4.1.1)
*** Bug 130747 has been marked as a duplicate of this bug. ***
*** Bug 130903 has been marked as a duplicate of this bug. ***
Should be solved now. Xisco: backport to 6.4?
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.
(In reply to Heiko Tietze from comment #44) > Should be solved now. Xisco: backport to 6.4? sure!
(In reply to Heiko Tietze from comment #44) > Should be solved now. Xisco: backport to 6.4? would be highly appreciated!
*** Bug 131119 has been marked as a duplicate of this bug. ***
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.
*** Bug 131139 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 131429 has been marked as a duplicate of this bug. ***
Problem has been fixed for me as of Version: 6.4.2.2
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.
*** Bug 130667 has been marked as a duplicate of this bug. ***
I have 1366 x 768 screen resolution. Mate desktop, with top and bottom panels - and the print dialog is too high.
@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.
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)
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).
*** Bug 131689 has been marked as a duplicate of this bug. ***
Created attachment 159145 [details] Failing dialog size
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
Created attachment 159146 [details] working dialog
*** Bug 131741 has been marked as a duplicate of this bug. ***
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)
The issue has been solved in version 7.0, 6.5, and 6.4.1.
(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.
On Mac os, french print dialog is still too high because of two-lines translation (
Created attachment 159415 [details] French print dialog
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.
(In reply to Heiko Tietze from comment #72) > 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. Why do you think it's not available? Did you try it yourself ?
(In reply to Xisco Faulí from comment #73) > Why do you think it's not available? Did you try it yourself ? See last 10 comments.
My fault, ui patch was done independently and hasn't been backported. On it's way now...
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.
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 :)
According comment 9 it shouldn't be a nuisance. Please resolve when done.
but it is. No, there's nothing scrollable to reach OK. But even if it was, this would be a nuisance.
(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.
Created attachment 159594 [details] LO 6.4.4's print dialog fits OK inside my 1366x768 screen
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
Created attachment 159596 [details] 1280x720px Gnome3 It fit's on a 1280x720 screen
Created attachment 159597 [details] Fits OK on 1024x768px Gnome3
Created attachment 159598 [details] Does NOT fit on a 960x720px
(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!
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
Yes Rene In your provided video we can see what i was trying to explain to Heiko, even with LO 7 Thanks!
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?
(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 ;-).
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
(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
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.
(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
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.
(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.
Created attachment 159920 [details] PrintDialog LibreOffice 7.0 daily build (Gnome/Adwaita theme)
Created attachment 159922 [details] PrintDialog more clicked LibreOffice 7.0 daily build (Gnome/Adwaita theme)
(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]
*** Bug 132407 has been marked as a duplicate of this bug. ***
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.
(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 [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)
*** 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 [details] 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 [details] 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.