https://bugs.freedesktop.org/show_bug.cgi?id=66901
--- Comment #7 from Owen Genat <[email protected]> --- Created attachment 90394 --> https://bugs.freedesktop.org/attachment.cgi?id=90394&action=edit SVG exports of slide 1 and 3 (from orig ODP) and some screenshots. Like bug #66900 this is a rather general bug report, which touches on several different issues. While there does appear to have been a regression in the handling of certain objects in SVG within Impress, the situation with SVG handling has many associated bug reports and is not simple, particularly since v4.0. The ODP provided in comment #0 contains three slides (s1, s2, s3), each with a single SVG. I have not dealt with s2 as is essentially the same as s1. Here are some details about the SVGs: s1: Source: http://openclipart.org/people/emilie.rollandin/diagramma_a_torta_2.svg Generator: Adobe Illustrator 15.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0 s3: Source: http://upload.wikimedia.org/wikipedia/commons/7/74/Normal_Distribution_PDF.svg Does not validate as SVG 1.1 + XHTML5 + MathML 3.0: Line 4, Column 232: Inkscape element grid not allowed as child of Sodipodi element namedview in this context. Error refers to this line: <inkscape:grid id="GridFromPre046Settings" type="xygrid" originx="0px" originy="70px" spacingx="5px" spacingy="5px" color="#0000ff" empcolor="#0000ff" opacity="0.2" empopacity="0.4" empspacing="5" visible="true" enabled="true"/> The validation error for the s3 SVG does not appear to be related as removing the problem element ensures validation, but does not fix the exporting issue described here. I opened the ODP under Ubuntu 10.04 x86_64 running: - v3.3.0.4 OOO330m19 Build: 6 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a I then exported s1 and s3 to SVG under each of these versions. While there are some small differences between v3.3.0.4, v3.4.6.2, v3.5.7.2, and v3.6.7.2 the resulting SVGs are largely OK. In both v4.0.6.2 and v4.1.3.2 however there is a significant degradation in the handling of: a. Bounding for gradient fills (refer s1 examples). b. Complete lack of support for exporting chart object (refer s3 examples). I have included screenshots in the case of s3 to show what I am seeing on screen, as the chart entirely fails to export, even though a lot of data is seemingly written the exported SVG. These would appear to be the two main problems described in this report. Given that the problem only applies to v4.0 and later, this report may be another artefact of bug 62284. Problem (a) would also appear to be related to bug 47441 (and there are many similar bug reports in the 47000-49000 range dealing with specific import / export filter details). Problem (b) is a more serious regression, exhibiting the type of behaviour in the attachment to comment #4 for the v4.0 series. The exported SVG for s1 v3672 contains a large ECMAScript. The exported SVG for s1 v4062 shows a doubling in size (over v3672) as a result of the SVG only appearing to contain an large embedded raster object. The exported SVG for s1 v4132 is smaller (although still large) as a result of containing many path fill commands e.g., > <path fill="rgb(230,40,43)" stroke="none" d="M 18029,12826 C 18029,13628 > 17847,14310 17446,15005 17045,15699 16546,16198 15851,16599 15157,17000 > 14475,17183 13673,17183 12872,17183 12190,17000 11495,16599 10801,16198 > 10302,15699 9901,15005 9500,14310 9318,13628 9318,12826 9318,12024 9500, > 11343 9901,10648 10302,9954 10801,9455 11495,9054 12190,8653 12872,8470 > 13673,8470 14475,8470 15157,8653 15851,9054 16546,9455 17045,9954 17446, > 10648 17847,11343 18029,12024 18029,12826 L 18029,12826 Z"/> This tends to indicate large changes in the manner in which LO exports to SVG under recent series. I imagine this report is essentially a duplicate of several other bug reports that together describe the same problems indicated here. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
