Hi Bastián, sorry I don't understand. Could you give more detailed steps to reproduce? Perhaps screenshots of what is expected/unexpected if possible.

How you create your attached PDF? I saw different result compare to your ODP attached by LO 4.0.4.2 (Win7 32bit)

(In reply to comment #1)
> Hi Bastián, sorry I don't understand. Could you give more detailed steps to
> reproduce? Perhaps screenshots of what is expected/unexpected if possible.


Is a little difficult to send a screenshot than I expect, that the bug still prevents me.

This happens only in cases in which is embedded a vector image (SVG) within the presentation, then this presentation is exported to vector format (SVG).

Steps to Reproduce:
1.create a presentation (eg 2 slides)
2.embedded in one of the slides one image in SVG format (example openclipart)
3.embed on another slide other image (PNG, JPEG, etc.)
4.save presentation. After both slides export SVG format (individually, but they overlap)

results:
The slide with a SVG image is deformed to be exported, however the slide with another type of image (PNG, JPEG, etc), no changes.

*The comment 0 attached several examples explained below:
→ the file "test 2.odp" is the test file
→ the file "test 2.pdf" shows no visual differences when exporting to PDF
→ the file "test 2A.svg" SVG export is the first slide in ODP file.
→ the file "test 2B.svg" SVG export is the second slide in ODP file.
→ the file "test 2C" export to SVG is the third slide in ODP file. (is the most extreme case, as the image disappears when exported)

I hope now you can understand.

Created attachment 82438 [details]
Comparison of presentation and outcome exported SVG

Sending a screenshot showing the left as you view the presentation (ODP) and right the exported ODP in vector format (SVG). You will see how the image on the right is all deformed.

Created attachment 82439 [details]
Screenshot from LO 4.0.4.2

Unfortunately I can't confirm this bug since I saw different result (another problem) while viewing your attached ODP.

(In reply to comment #4)

> Unfortunately I can't confirm this bug since I saw different result (another
> problem) while viewing your attached ODP.

If you can not replicate the problem I've reported, you can not say "can not confirm" (if successfully replicated and do not get the same results, then you can say that is not confirmed). Besides this using an older version of LO (check display problems with SVG files in earlier versions of LO).

Try testing with another SVG image (one that you can see) and replicate the problem.

Hopefully a developer check the bug.

> If you can not replicate the problem I've reported, you can not say "can not
> confirm" (if successfully replicated and do not get the same results, then
> you can say that is not confirmed). Besides this using an older version of
> LO (check display problems with SVG files in earlier versions of LO).
You're right. Thanks for the correction :)
 
> Try testing with another SVG image (one that you can see) and replicate the
> problem.
I've tested similar case on your previously reported bug ;)
https://bugs.freedesktop.org/show_bug.cgi?id=61314#c4

Anyway that's not reproducible using LO 3.6.6.2 (Ubuntu 12.04 32bit).
Perhaps someone could confirm & marking whether it's a regression.

Created attachment 90394 [details]
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.

As per comment #7 confirmed (in that I am seeing / experiencing the same issues). Status set to NEW. Version set to 4.0.4.2 release as a result of comment #1 and comment #4, although it probably relates to all of v4.0.

(In reply to comment #8)
> As per comment #7 confirmed (in that I am seeing / experiencing the same
> issues). Status set to NEW. Version set to 4.0.4.2 release as a result of
> comment #1 and comment #4, although it probably relates to all of v4.0.

(In reply to comment #7)
> Created attachment 90394 [details]
> 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:
> 

If lack specificity when submitting the error is due to my inexperience when creating bug reports more efficient. I hope to correct that in the future.

Thank you.

(In reply to Bastián Díaz from comment #3)
> Created attachment 82438 [details]
> Comparison of presentation and outcome exported SVG
> 
> Sending a screenshot showing the left as you view the presentation (ODP) and
> right the exported ODP in vector format (SVG). You will see how the image on
> the right is all deformed.

Reproduced.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 01a189abcd9a4ca472a74b3b2c000c9338fc2c91
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-14_07:46:28
Locale: fi-FI (fi_FI)

export to SVG one by one slide from

Version: 6.3.0.0.alpha0+
Build ID: ba17d2e3c1acd571a4faa7e31ef97a2ec71591bd
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-12-10_01:14:49
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

looks fine (see attach)

ps: may be onle left legend in graph on slide 3 looks some badly, but it's another problem I think

Status->WFM

Created attachment 147450 [details]
SVG from 6.3 a0