Created attachment 128214 [details] PPTX2010 file A bracket is not correct. It seems to be transformed into a line from the top-left corner to the bottom-right corner.
Created attachment 128215 [details] PPTX2010 correct element
Created attachment 128216 [details] LO5 bad element rendering
Confirmed. Regression as it works correctly in 3.4.6. Version: 5.3.0.0.alpha1+ Build ID: 928776b734c6aa188151bbce048d5bef4486dce7 CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-10-23_00:39:08 Locale: en-US (en_US.UTF-8); Calc: group
Added a block on Impress-Images ... feel free to remove (or assign to other meta bugs) if brackets are not considered images.
(In reply to internationils from comment #4) > Added a block on Impress-Images ... feel free to remove (or assign to other > meta bugs) if brackets are not considered images. Yes not images. @Xisco, @Aron: Got time for a bibisect?
Bibisected using repo bibisect-43all: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e5f71ca7c27259360a401d94ed6a53038608b941..73ec894e0d5aea6f8462c2e42d064c317d4a82ec
Created attachment 135756 [details] Another sample It seems the extreme curve setting is what isn't handled correctly. See attached sample with two brackets and nothing else, the rounded bracket displays fine, while the rectangular bracket doesn't. Looks like the regession is from one of the commits by Radek Doulik in the bibisected range. The relevant code is probably here (leftBracker / rightBracket): https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/customshapes/presetShapeDefinitions.xml
** 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
Hello, nothings changed, still present. Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: en-US (en_US.UTF-8); Calc: group
Since this is a regression (see the analysis from Aron above) and the relevant code has been identified, can someone please look at this? Issues like this are preventing LO from being used as a drop-in presentation tool for PPT files, and this is not helping adoption / migration from the MS Suite...
The error is in case ARCANGLETO in EnhancedCustomShape2d::CreateSubPath in svx\source\customshapes\EnhancedCustomShape2d.cxx The bracket consists of a quarter ellipse, a straight line and another quarter ellipse. In case the handle is dragged to its top most position, the ellipse has a height of zero. In this case a straight line should be used for the degenerated quarter ellipse. But the current implementation generates no point at all, so that only the middle segment is drawn. I have not yet investigate, whether it is better to add a special case handling here and still use the methods from /tools/, or change it completely to use basegfx methods similar to ANGLEELLIPSE.
Created attachment 161744 [details] Bracket build with command T Using command T instead of command G has a similar error. When the circle angle is calculated from the ellipse angle, the angle is wrong in case of height=0 and angle=180°, if using atan2. This corner case has to be caught beforehand.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/91f06123298bb8870cd6fa4e19d3aea9909f8e5b tdf#103474 handle quarter angles before using atan2 It will be available in 7.1.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.
The commit solves the problem for the command T. It does not solve the problem for command G, but it is a needed step.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/a7eef5557060504e6e185e8cd8d9acaf6431cd16 tdf#103474 handle quarter angles before using atan2 It will be available in 7.0.0.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.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6de8d3109dffa7d4d0cc06f319cca70134f0a8f3 tdf#103474 handle edge cases in ARCANGLETO It will be available in 7.1.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.
Should be OK with this fix now.
Verified in Version: 7.1.0.0.alpha0+ Build ID: 11d21b3c1f7754b5d13ae9ea88da562ec74366ff CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Regina, thanks for fixing this issue!!
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/6eaa80f5c40619d8d27c1e5dc180bd2289bd3559 tdf#103474 handle edge cases in ARCANGLETO It will be available in 7.0.0.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.
*** Bug 133475 has been marked as a duplicate of this bug. ***