Created attachment 106486 [details] Test file Open 'intersect_bug.odg', select circle (A) and ring (B) objects, run Modify->Shapes->Intersect. The resulting polygon (A ∩ B) must be equal to ring (B), not to A \ B. Tested with version 4.4.0.0.alpha0+ (f39ed4c680fe8ef2ea3f0ace91ea3175551ec9c5)
Created attachment 106487 [details] Graphical explanation
Confirmed on Windows 7 sp1, 64-bit en-US with Version: 4.3.4.1 Build ID: bc356b2f991740509f321d70e4512a6a54c5f243 and Version: 4.4.0.0.alpha2+ Build ID: 9229170920ab770624415c4330da57af5b1b5398 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-09_03:16:43
** 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 on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Problem persist: Version: 5.0.4.2 (x64) Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale: it-IT (it_IT)
** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
Steps to reproduce with changes to menus, but issue remains with Version: 6.1.4.2 (x64) Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: en-US (en_US); Calc: CL and current master/6.3.0
Dear vvort, 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://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
Still in: Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 24; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); Interfaccia utente: it-IT Calc: threaded
Dear vvort, 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
Created attachment 193207 [details] Modified sample ODG illustrating how line thickness and Z-order matter Still as described in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Same in OOo 3.3, so behaviour is inherited. But to me it is not clear that this is a bug, or what the bug is: - I understand the intersection to be "everything that is contained in all of the objects simultaneously"[1], which for two overlapping circles, with a line thickness of 0, would include a fill if it exists. - If the line has a non-zero thickness, and there is no fill, then it makes sense to use that ring for the intersection. - In the sample file, the grey disc is a "Bézier curve", and the circle is "polygon with 400 corners". I'm not sure why the object is presented as an empty pink circle when its Line has "Style: none" and its area is filled with pink. - LO uses the object styling (area fill, line properties...) of the object that is behind for the resulting intersection object. In the original sample, the circle is at the front, so the styling used is the grey disc's. If the Z-order is switched, the result is a pink disc. - If the objects are copied, result is different: 0-corner polygon regardless of Z-order. See attached modified sample, with shape examples illustrating how Z-order and line thickness matter. IMO, the actual issues are: * Display of original objects: - line visible even though it's set to "none", uses fill colour; - no fill visible even though it is set to solid colour; * Intersection of copies results in 0-corner polygons. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 479b5bbe8ca2177ba7574e7aa2308b5d0de1895c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded [1]: https://en.wikipedia.org/wiki/Intersection
Regina, do you have any insights regarding my comment 10? (In particular on differences between object types, my knowledge is limited on the topic.)
I'm not an expert with "intersection". But Armin should know. The relevant methods are https://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdedtv2.cxx?r=b26ddd42&fi=MergeMarkedObjects#991 and https://opengrok.libreoffice.org/xref/core/basegfx/source/polygon/b2dpolypolygoncutter.cxx?r=7979508e&fi=solvePolygonOperationAnd#969 As far as I know, there are these principles: (1) Intersection is done on the area which is enclosed by a polygon. (2) Objects are converted to contour during the intersection process. Thus an object with a hairline stroke becomes one object, but an object with a thick stroke becomes two objects, one for the stroke and one for the fill. (3) The resulting object gets the style of the object furthest back. The "Test file" (attachment 106486 [details]) has a "ring" object which is a polypolygon with stroke none, fill color #ff9999 and 0% transparency, and a "circle" object which is a path with stroke none, fill color #dddddd and 50% transparency. The "ring" is in front. It looks as if it is completely on the area of the "circle". Therefore I expect as result of intersecting a ring with stroke none, fill color #dddddd and 50% transparency. So for me it is a bug. There might be a problem with working in integer, because the coordinate differences between outer part of ring and circle are in range of 1/100 mm. When you first convert the circle (which is a Bezier curve) to polygon and then intersect the objects, then you get the Gray ring I expect.