Issue also affects impress in addition to draw. Issue has been tested with the kde integration and without the gnome integration packages on kubuntu 14.04, using the libreoffice packages distributed on the libreoffice site (not the distro ones). Problem description: Since LibO 4.2 the 'line and filling toolbar' and the 'text formatting toolbar' have slightly different heights (maybe 1-2 pixels). Up to LibO 4.1 all toolbars had exactly the same height. As a consequence, when one needs to draw something that is just a bit complex, the drawing continuously jumps up and down by a few pixels, whenever one selects or unselects text. This is very annoying, you feel like trying to prepare a drawing while standing on the tube since the pictures moves under your eyes. The issue is present with the automatic and small settings for the icon sizes and not with the large icon size. I suspect that it may also manifest differently depending on the screen resolution, etc. However, my point of view is that the toolbars should have a fixed height, no matter what. Operating System: Ubuntu Version: 4.2.0.4 release Last worked in: 4.1.6.2 release
Cannot confirm - Ubuntu x64 LibreOfficeDev 4.5 daily build Image attached. Please test with 4.2.4 (not sure why you're still on 4.2.0). Also - it's always recommended to use a ppa with Ubuntu/Kubuntu - https://launchpad.net/~libreoffice/+archive/libreoffice-4-2 The package is NOT the same as the one on libreoffice.org. Install that ppa, pure libreoffice, install libreoffice (you'll have 4.2.4) and then test again. If you can still reproduce - give us a good screenshot with some magnifying program showing the toolbars and mark the bug as UNCONFIRMED. Thanks
Created attachment 99373 [details] Image Showing Good Toolbar Height
Actually, I am on 4.2.4.2. In the bug report I filled in the first version of LibO in which the bug appeared. Tested with LibO from libreoffice.org to make sure it was not due to ubuntu build. As mentioned, bug appearance depends on the combination of DPI and icon size you use, which is why you may not be able to see it. The point is that LibO 4.1 never showed this issue at any DPI and icon size and does not show the issue when run on the same machine, with the same config. I am making the bug visible with a couple of screenshots. The attached picture is a montage of two screenshots made with the print screen functionality. Montage is done with imagemagick to assure that the images are aligned to the pixel. Montage is then imported into an image editor itself, in order to add a couple of horizontal and vertical red lines that help noticing the skew in the drawing canvas positioning due to the different toolbar height. Specifically, screenshot A is taken with line and filling toolbar, screenshot B after selecting text in order to make the text formatting toolbar substitute the line toolbar and filling. Screenshots A and B are then mounted as A B B This lets both the horizontal and the vertical alignments be checked. Red reference lines are placed around the toolbar and at the edges of the letter 'T' in the drawing canvas. As evident, the text formatting toolbar is two pixels taller than the line and formatting toolbar. As a result, when the text is selected and the text formatting toolbar appears, the text itself jumps down two pixels, when text is deselected, the text jumps back up two pixels. Now, two pixels may seem like nothing. But when you are trying to do precision aliments and you frequently alternate text and non text selections, having the image moving up and down even by two pixels is an issue that makes you go back to LibO 4.1 immediately, regardless of the other advantages that LibO 4.2 may have.
Created attachment 99470 [details] Snapshot montage showing the different toolbar height
Version is the oldest version not latest. We just leave comments if the bug still exists on later versions.
Can someone try this configuring the screen on linux at different resolutions? In my case, it looks like the issue impact is different at different resolutions. For instance: 96dpi -> almost negligible 120dpi -> visible 125dpi -> more visible so, can anyone please try the following on linux kde? 1) configure kde for 125 dpi (settings->application appearance->fonts->force dpi) or even some absurdly large dpi such as 195 2) configure libreoffice for small toolbars 3) libreoffice --draw 4) add a text box with some text in it. Add a rectangle. 5) switch between text selection and rectangle selection 6) see if the page area moves during the switch.
Bug reprodused. I'm using Ubuntu 14.10 with KDE(4.14.1) and LibreOfficeDev Version: 4.5.0.0.alpha0+ Build ID: dad173d9588e6abc2a465198b7d2881d4629246a TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-12-10_22:53:28
Setting to NEW per comment 7.
Encountering this in 4.4.4.3. Did not encounter this before. It means if I select one thing, the whole drawing moves, and if I try to select two things, I may not select the right two things. Major usability bug.
*** Bug 73779 has been marked as a duplicate of this bug. ***
Bug 73779 reports the same problem in 4.1.4.2. Which pushes the earliest affected version back.
Migrating Whiteboard tags to Keywords: (possibleRegression)
I'm seeing this again in 5.1.0.3 while LibO 5.0.5.1 does not have the issue on the same machine. In draw, the "line and filling toolbar" is higher than the other toolbars (e.g. the "standard" toolbar). This makes editing drawings extremely annoying whenever the toolbar is docked at the top. Depending on which graphical element you click on, the toolbar appears or disappears, making the whole drawing jump up and down by a few pixels. Machine runs Kubuntu Linux 15.10.
5.1 and 5.1.1 RC 1 both have the issue. The issue is bad enough to make working on draw/impress extremely tiresome to the eyes, to the point that sticking with version 5.0 is the only way to have work done. Tried removing individual elements from the toolbar with "customize toolbar" leaving only buttons, as I had the expectation that it was the textual or dropdown items causing the issue, but it did not make any difference.
Regression is solved by removing the KDE integration package.
I have made some more checks on this. The item does not affect all of my machines. I have one of them that does not show the issue, even if the configuration is very similar to the others. Maybe the issue is not triggered on all screen resolutions / font sets.
Affects OS X in 5.1.1.3.
In OS X, the "Line and Filling" toolbar keeps disappearing, especially when I select text, sometimes other times, so it's not a different toolbs have different heights issue as "how do I keep the toolbar from disappearing?" Everything jumps up and down. I am getting a migraine, and need some way to keep things from jumping up and down.
Is it possible to include a space, at the top of the window, for one or two toolbars? This would keep toolbars from moving the drawing when they appear/disappear.
(In reply to MarjaE from comment #19) > Is it possible to include a space, at the top of the window, for one or two > toolbars? This would keep toolbars from moving the drawing when they > appear/disappear. Please don't conflate issues. Write new enhancement requests for these types of things (last comment also). Thanks
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d72f2a5e911cd4162695370fb598036b0a5351d1 tdf#78924 KDE4 drop special Combobox code It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED?
A polite ping to Jan-Marek Glogowski: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to sergio.callegari from comment #13) > I'm seeing this again in 5.1.0.3 while LibO 5.0.5.1 does not have the issue > on the same machine. > > In draw, the "line and filling toolbar" is higher than the other toolbars > (e.g. the "standard" toolbar). > > This makes editing drawings extremely annoying whenever the toolbar is > docked at the top. > > Depending on which graphical element you click on, the toolbar appears or > disappears, making the whole drawing jump up and down by a few pixels. Can repro with the new kde5 backend. Activate View - Toolbars - Text formatting. Drag it under the Standard toolbar. Activate View - Toolbars - Line and filling. Drag it to the bottom. Now focusing back and forth to the text in a text box and shape selection, the Text formatting and Line and filling toolbars appear depending on your focus. The Line and filling toolbar is clearly higher than Text formatting. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 1 January 2019
(In reply to Buovjaga from comment #25) > Can repro with the new kde5 backend. > > Activate View - Toolbars - Text formatting. Drag it under the Standard > toolbar. > Activate View - Toolbars - Line and filling. Drag it to the bottom. > > Now focusing back and forth to the text in a text box and shape selection, > the Text formatting and Line and filling toolbars appear depending on your > focus. > > The Line and filling toolbar is clearly higher than Text formatting. > > Arch Linux 64-bit > Version: 6.3.0.0.alpha0+ > Build ID: 2c7b0030b40de00e8c9ab997bdfe83631861968a > CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: kde5; > Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US > Calc: threaded > Built on 1 January 2019 Is that still the case? If so, can you attach a screencast that shows the issue? I seem to be unable to reproduce on Debian testing with Version: 7.0.0.0.alpha0+ Build ID: 718f540fb63af27c1336f89213444e9af753b8a9 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
Well, the behaviour has changed in that after Text formatting disappears, it does not come back! Let's close I guess.