Created attachment 189004 [details] Path object Open attached document. It has a closed path object. That is a <draw:polygon> in markup in file. Select the object. Switch to point edit mode. Its toolbar has an icon to toggle open/close. Use it and open the object. Because it is open, it is no longer filled. That is correct. Save the document and reload it. Error: The object is closed again. It is a save error. The opened object is written as <draw:polygon> whereas it has to be a <draw:polyline>. It was OK in Version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) It is broken in Version: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: en_US I haven't got versions between to narrow it further. [I thought that it is likely that a bug report exists already, but I couldn't find one.]
In XMLShapeExport::ImpExportPolygonShape, the export uses the property "Geometry". That gives a drawing::PointSequenceSequence in this case. That is transformed by basegfx::utils::UnoPointSequenceSequenceToB2DPolyPolygon(). That uses UnoPointSequenceToB2DPolygon(). And there with checkClosed() method the last point is removed and the polygon is set to "closed". With commit 56775815a39c2 the parameter bCheckClosed in UnoPointSequenceToB2DPolygon() was removed. But it would have been needed in export. Armin: Where should the problem be fixed? Introduce a new way in ImpExportPolygonShape, which does not go over UnoPointSequenceToB2DPolygon, or reintroduce the parameter bCheckClosed and use is in export?
Thanks Regina. Reproduced in recent master build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 695ae365dcab7c7dd59b39411299c5c200081885 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Bibisecting with linux-64-releases, the first affected release was 4.2.0.0.beta1 (first bad commit in repo is 81670b1d7fce4d919e8511349b15604e1cafd071). So looks like the same cause as in bug 106500 comment 1. Do you think the two issues need to be handled separately, or is this a duplicate?
(In reply to Stéphane Guillou (stragu) from comment #2) > > Bibisecting with linux-64-releases, the first affected release was > 4.2.0.0.beta1 (first bad commit in repo is > 81670b1d7fce4d919e8511349b15604e1cafd071). > 404 Not Found - Stephane, is it correct guid?
(In reply to raal from comment #3) > 404 Not Found - Stephane, is it correct guid? It's the build commit, so the automatic linking wouldn't lead anywhere. Setting back to "bibisectRequest" for someone to bibisect in 4.2 before beta1.
This seems to have begun at the below commit in bibisect repository/OS bibisect-42max. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks 0fa5d05a040d6b16fada649b7f92460fcbfdd4d5 is the first bad commit commit 0fa5d05a040d6b16fada649b7f92460fcbfdd4d5 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 22:37:23 2015 +0800 source-hash-223f6b631c1b087754c0f9051fb55f029f2503ce commit 223f6b631c1b087754c0f9051fb55f029f2503ce Author: Armin Le Grand <alg@apache.org> AuthorDate: Tue Oct 29 14:11:45 2013 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Thu Oct 31 15:56:14 2013 +0000 Resolves: #i123433# Detect pseudo-vertices at svg import... unify svg:d handling, correct svg:d import for relative sub-polygons in svg import; changed default for moveto writes for svg:d in ODF to absolute (cherry picked from commit f15874d8f976f3874bdbcb53429eeefa65c28841)