Context: ************** Draw document with curved connectors created in 5.x version. The connectors paths are nicely set between the connected objects. Upgrade of LibreOffice to 6.x version. Same document opened again. Finding ************** The connectors paths are now totally messed up: they are doing huge detours. If try to control their path: doesn't work. If try to delete a connector and recreate a new one: same, the new connector's path is following a huge arc ans is impossible to reduce. Expected ************** - Curved connector path stay the same when upgrading from 5.x to 6.x - Curved connector path controllable in 6.x - Curved connector path newly created in 6.x by default make no detour between the 2 connected objects
please attach your document from LO 5.x here
Created attachment 152571 [details] DRAW file created in Libre Office 5.x
Requested file attached
Created attachment 152574 [details] How it looks in LibreOffice 5.2 alpha1
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9886a69c472f212d88f11cfa0f3835e5dcf485b2..735d9e5828157a09e0b04b2dc5797a78208b57a2
I know how to fix it...
*** Bug 122955 has been marked as a duplicate of this bug. ***
*** Bug 116940 has been marked as a duplicate of this bug. ***
Created attachment 152596 [details] Example reduced I think, that it is duplicate to bug 120350. The "missing" lines there are wrongly placed at the left top of the page and make the flow-chart objects much larger than they are, and therefore force the routing of the connector a wrong way. I have attached a file, were I have removed most of the objects of the original file. That makes it easier for testing. Open the file in LO 54 and move the objects to a position left-top of the magic 42cm. Or open the source of the file and remove the additional N command in the path (see bug 120350). In both cases the connectors will be fine, if you then open the file in a current LO version. Do you have tested, that reintroducing the hack will not again result in bug 37559 and its duplicates?
*** Bug 117826 has been marked as a duplicate of this bug. ***
*** Bug 120350 has been marked as a duplicate of this bug. ***
*** Bug 117910 has been marked as a duplicate of this bug. ***
(In reply to Regina Henschel from comment #9) > Created attachment 152596 [details] > Do you have tested, that reintroducing the hack will not again result in bug > 37559 and its duplicates? Good point, in the end, I've re-introduced the hack and reduce its scope, so testQuadraticCurveTo::TestBody and testViewBoxLeftTop::TestBody pass. Regarding bug 37559, I'll ask Mike Kaganski to reproduce it with my patch, I can't reproduce it myself. Give it a try if you have a chance too...
Your patch introduces additional points top-left and bottom-right. It is not as bad as in bug 37559. They are only visible in edit mode at some zoom level and not directly written to ODF file format. But if the shape is converted to curve, some things happen, where the user cannot know, what happens: The additional points are written as single moveto add the end of the path. So they could be ignored in opening. But LibreOffice reads them and uses them for calculating frame and bound box. That becomes visible, if the object is rotated. If the document is written to pptx, the additional points in (to curve converted) shape are written as moveto lineto. And this moveto lineto is kept on reopening. So the geometry gets two zero length paths. As long as "cap" is not implemented for zero length path, they are not visible. But from svg:d definition they should be visible, if a cap is defined in the line style. And I'm concerned, that it is not clear, why the inner lines of the shapes are not rendered correctly, if the shape is beyond 42cm.
My test were for your version #3, need some time to look at version #4.
Created attachment 152607 [details] Resulting PDF Some more tests, now with your version 4. The dots top-left and bottom-right are created and exported to pdf. They are visible in Acrobat Reader and in Chrome. To see the dots, use a line style with true line width, no hairline, and set the cap to round. The problems from bug 37559 would be there again. To see the dots in LibreOffice without converting to curve, disable anti-aliasing and reduce zoom, or look at the thumbnails in the slide pane or look at the slides in the slide sorter. The problem, that the additional points produce a different bounding box exists for custom shapes too, not only for the shapes, which are converted to curve. This difference influences the text layout in Writer, if the shape uses a wrap with text besides the shape, "page wrap" e.g, without contour.
Use document "Path M L N M L" https://bugs.documentfoundation.org/attachment.cgi?id=148736 from bug 120350 and open it step-by-step. You will come to viewcontactofsdrpathobj.cxx#95. There the pointer pPage is NULL. That will result in a page size of width=21000 and height=29700 in line 106/107 and the in a clip range of x in -21000..42000 and y in -29700..59400. That explains the magic 42cm. But of cause the questions remain, why is pPage=NULL, and why appear the lines, which are dropped because of the clip range, in the top-left corner of the page?
Hi Regina, Could you please attach the original file from comment 16 ?
Created attachment 152624 [details] RoundedRectangle.odg, orig file for the pdf
(In reply to Regina Henschel from comment #19) > Created attachment 152624 [details] > RoundedRectangle.odg, orig file for the pdf I've just submitted a new patch to gerrit that fixes this specific problem. Just to be clear here: I don't know the code so I'm just doing try/error until I see everything works and the tests pass. @Regina, if you have a better and more elegant solution here, please go ahead a implement it, you know the code much more than I do
Created attachment 152632 [details] AdditionalDot.odp, Example with arrow line end The version 5 does not work. The dots are still there. In addition a line arrow is shown on a closed polygon. I think, that it is a wrong attempt. See my comment#17. I think it is necessary to find the root cause for the NULL pointer.
Putting this issue back to NEW, if I re-introduce the hack as in https://gerrit.libreoffice.org/#/c/75143/, bug 37559 is reintroduced as well. it has to be fixed in a different way...
The problems have started with the fix for bug 63955. That fix introduced a clipping to a rectangle, which was build from a page size. But that page size doesn't exist as expected by the fix. That led to bug 97276, bug 97276, bug 98366 and bug 101187. Each of them where "fixed" by adding a special case to the fix from 63955. And now the fix from 63955 leads to the problems in this bug and its duplicates. If I remove the clipping (currently lines #88 to #121 in viewcontactofsdrpathobj.cxx), all the mentioned cases work fine. Only bug 63955 would not be fixed. But the problematic document in bug 63955 was created from a binary *.sdd file. The creation process was badly done. I had created a correct conversion at that time, which opens fine. So my suggestion is, to remove lines #88 to #121 and find a better solution to prevent LibreOffice from crashing with problematic files. [The problem in the file from bug 63955 is a 19km long line.] I would also like to draw attention to the concerns about the fix expressed by Armin in the bug report 63955.
(In reply to Regina Henschel from comment #23) > So my suggestion is, to remove lines #88 to #121 and find a better solution > to prevent LibreOffice from crashing with problematic files. [The problem in > the file from bug 63955 is a 19km long line.] I would also like to draw > attention to the concerns about the fix expressed by Armin in the bug report > 63955. Hi Regina, Thanks for the great analysis, indeed I do confirm removing that chunk of code would fix the issue. @Caolán, Do you think bug 63955 could be fixed in a different way ? See < https://bugs.documentfoundation.org/show_bug.cgi?id=63955#c19 >
I'm all ears on an alternative fix
*** Bug 127366 has been marked as a duplicate of this bug. ***
(In reply to Caolán McNamara from comment #25) > I'm all ears on an alternative fix Given my very limited knowledge of drawinglayer, I'd leave implementing a new approach to somebody more capable in this area... For now, I've created https://gerrit.libreoffice.org/#/c/78690/ to increase the limits for clipping to use the max paper dimensions. Comments welcome, since I'm far from being an expert in this area...
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/1dccd6814f1fe7a06f3168d01d18d347269cd3c1%5E%21 tdf#126184 Use max paper dimensions to calculate clip region It will be available in 6.4.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.
Per the suggestion at the bottom of https://cgit.freedesktop.org/libreoffice/core/commit/?id=1dccd6814f1f I created Bug 127424
(In reply to Luke from comment #29) > Per the suggestion at the bottom of > https://cgit.freedesktop.org/libreoffice/core/commit/?id=1dccd6814f1f > > I created Bug 127424 Thanks. Let's mark this one as fixed, since the behaviour described here and in the duplicates is fixed by the above commit. Pending backport for 6.3: https://gerrit.libreoffice.org/#/c/78759/
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/859f49294ad95d3a6596e135e550253155d6517b%5E%21 tdf#126184 Use max paper dimensions to calculate clip region It will be available in 6.3.3. 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.
Verified in Version: 6.4.0.0.alpha0+ Build ID: f4f8bccbd4e2c3979a83d5b2f49e16a99a3a2016 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Michael Weghorn, thanks for fixing this issue!!
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/e49eb6c9968f3ccc4e24c3f0444221c20aefb7aa%5E%21 tdf#126184 Use max paper dimensions to calculate clip region It will be available in 6.2.8. 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 128031 has been marked as a duplicate of this bug. ***
*** Bug 123028 has been marked as a duplicate of this bug. ***
*** Bug 124993 has been marked as a duplicate of this bug. ***