Created attachment 59244 [details] W3C SVG test suite "painting-stroke-03-t" "The two paths should be rendered as two blue line segments. The upper segment should have round end caps. The lower segment should be chopped off where the two line segments meet."
Thanks for bugreport Link to site: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/painting-stroke-03-t.html reproduced in 3.3.4 on Fedora in both File->Open and Insert->Picture reproduced in 3.5.4 and 3.6.beta1 only in File->Open
NOT reproducible anymore with Version: 4.1.2.3 Build ID: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38
Ends of upper line still not round Reproduced in 4.1.2.3 on Fedora (RFR) 64 bit using File->Open Changing status to New
Minor summary edit to correct parameter name (was not showing up in searches for "miter").
*** Bug 92491 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (filter:svgOpen)
I have tested with a current daily build Version: 5.2.0.0.alpha0+ Build ID: 85fcf15ff41ceb95f46dee586ff7187551be4955 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-27_09:23:38 Locale: de-DE (de_DE) The round linecaps are drawn correctly know, if you _import_ the svg-image. If you use File>Open, the linecaps are still wrong. But it has been decided, that the File>Open algorithm will be dropped in favor of the import algorithm, so that only one algorithm has to be maintained. Therefore the problem linecap="round" do not need to be considered any longer. The problem "miterlimit" still exists and is relevant for svg import. I have found, that the method basegfx::tools::createAreaGeometry is prepared to use a miterlimit, but none of its callers uses this parameter. The relevant one seems to be method uno::Reference< rendering::XCachedPrimitive > CanvasHelper::strokePolyPolygon() in /core/canvas/source/vcl/canvashelper.cxx. It has some comments, which I read as if the feature miterlimit is yet not implemented.
Created attachment 123967 [details] stroke-miterlimit on text stroke-miterlimit can be applied to text to. The first line has stroke-miterlimit="10", the second line hat the miminum stroke-miterlimit="1".
Created attachment 124241 [details] Presentation with linked svg and screenshots
Regina Henschel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=32cec4ca8bf1e09dd33aa461984e8e8ae34f4a7c tdf#48066 render stroke-miterlimit correctly in SVG import It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Regards
No, it is only partly fixed. Presentation mode and pdf export is still wrong.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
LOO 5.4.2.1 64bit win 10 Presentation: bezier greater example right edge is wrong in limiter vertical border line is thicker
Created attachment 138026 [details] scaled bezier path is buggy in page 3 of odp 5.4.2.3 win64 win10 bezier path position dependent variation of right end
Created attachment 138027 [details] screenshot of page 3 in buggy scaled bezier path scaled bezier path variation in position on page. very strange. 5.4.2.3 64 bit win 10
in Version: 6.1.0.0.beta2+ (x64) Build ID: fe1a23b5c49c94410a604c8d4a6f50f43d575403 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-06-17_06:31:41 Locale: ru-RU (ru_RU); Calc: CL first attach file "W3C SVG test suite "painting-stroke-03-t" opens fine as described in bug report "The two paths should be rendered as two blue line segments. The upper segment should have round end caps. The lower segment should be chopped off where the two line segments meet." @Regina, can you check your examples in LO 6.1 beta 2, because i don't understand which result should be with it.
(In reply to kompilainenn from comment #17) > @Regina, can you check your examples in LO 6.1 beta 2, because i don't > understand which result should be with it. Each slide has the svg-image and a screen-shot of how it should look. In edit mode all is OK. But if you run the presentation or if you export the presentation to pdf, you see the errors. That problem still exists in Version: 6.1.0.0.beta1 (x64) Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (de_DE); Calc: CL and in Version: 6.2.0.0.alpha0+ (x64) Build ID: 2c85607101e2e04e870e3b87362f39f9a9148e6c CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-16_00:12:37 Locale: de-DE (de_DE); Calc: CL
(In reply to Regina Henschel from comment #18) > But if you run the presentation or if you export the > presentation to pdf, you see the errors. > I think, that it is another bug. Bug about correct export SVG to PDF. My opinion - close this bug as WFM and fill a new bug about correct export SVG to PDF.
Follow-up bug for rendering errors in presentation mode is bug 118255, errors in PDF export is bug 118256. The file first attached, renders now correctly in edit mode if inserted as image, and opening the file renders fine too after LO has switched to svgio for file open recently. Tested with Version: 6.2.0.0.alpha0+ (x64) Build ID: 2c85607101e2e04e870e3b87362f39f9a9148e6c CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-16_00:12:37 Locale: de-DE (de_DE); Calc: CL