Description: Here is how to reproduce the behavior: * Open LibreOffice Impress and create a new empty presentation * insert an "Arrow" object, e.g. using the toolbar group "lines and arrows" and then pick "Line ends with arrow". Draw this arrow with the mouse from left to right. * result: a nice arrow from left to right is displayed, so far so good. * now, in the side pane, go to the "line" properties of this arrow object. The currently displayed line endings are still "none" on BOTH sides. (This is the first thing that seems un-expected to me!) * change both line endings to something else, for example "small arrow" * result: a line with two arrow heads is displayed * BUT: the right arrow head is displayed much BIGGER than the left arrow head. And there is no way (I have tried hard) to create two arrow heads of the same size on this "arrow" object. * (The only way to achiev the desired result is to delete the whole arrow object, and to start all over with a "line" object. This works fine then.) This behavior is very unexpected for me. It forces me to delete my (formatting) work and to redo it all again (if I have the counter-intuitive idea of using a "line" object instead at all...) This irritating behavior has been in LibreOffice, and before in OpenOffice, for many years. But I couldn't find any open bug report for it any more. That's why I opened this one. I will attach a simple demo odp-file that easily shows the behavior I described. Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info:
I could still observe this in the "fresh" 6.3.0.4 version of LibreOffice.
Created attachment 153293 [details] demo odp-file to show the behavior added the demo opd-file
Thanks for reporting this issue. I can't reproduce it in Version: 7.0.0.0.alpha0+ Build ID: 28d844a589e52abfe62dc66b888e78665221ba28 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I have re-tested this with the current nightly build of LibreOffice, and I still DO see this! This is the LibreOffice version I used: Version: 7.0.0.0.alpha0+ Build ID: 7fddb9a1f69a1bac676ad48421256a1ba0274c83 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-02-16_19:33:19 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded This is what I observed: * When I open the attached odp file in Impress, then the lower arrow still has a bigger head at the right end. * When I create a new presentation and insert a new line object there, then I can still observe the 100% same behavior as described in my original post. In this new version of LO the misbehavior is even more obvious: In the right settings pane, where the line properties are displayed, you can now see that the right arrow head is always set to "nothing", none of the head icons is highlighted. Have you really followed my instructions in the original report and could not reproduce this? I have seen this for several years now, on many different computers, with Linux and Windows OS, and with many versions of LO.
The problem is a mismatch of the default width of the arrow to the default width in style "standard". The default width of the arrow is 300 (1/100th mm) in https://opengrok.libreoffice.org/xref/core/sd/source/ui/func/fuconrec.cxx?r=1902f1e4#682 The default width in style "standard" is 200 in https://opengrok.libreoffice.org/xref/core/sd/source/core/drawdoc4.cxx?r=4efe996e#156 Calc uses 2mm as default, Writer uses 1,76mm as default, but both only use automatic styles (=direct formatting). Looking at the mentioned i3908, other places to create a line have to be considered too. https://bz.apache.org/ooo/show_bug.cgi?id=3908 For me the real problem is not the value of the width, but the fact, that the arrow width is set at all. As long as the user does not apply a direct formatting, in Draw/Impress the defaults from the style should be used. @hardy: Chose "Line..." from the context menu of the line and set the arrow width to the values you need.
(In reply to Regina Henschel from comment #5) > For me the real problem is not the value of the width, but the fact, that > the arrow width is set at all. As long as the user does not apply a direct > formatting, in Draw/Impress the defaults from the style should be used. -> NEW
*** Bug 143411 has been marked as a duplicate of this bug. ***
Dear hardy, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I have re-tested with LibreOffice 24.2.2.2, and unfortunatelly this behavior is still present. Detail on my LO version: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded