Bug Hunting Session
Bug 66901 - SVG images within a presentation, deform (change aspect) to be exported in vector format.
Summary: SVG images within a presentation, deform (change aspect) to be exported in ve...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:svg
Depends on:
Blocks: SVG-Save
  Show dependency treegraph
 
Reported: 2013-07-14 14:50 UTC by Bastián Díaz
Modified: 2018-12-11 18:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Examples of the problem. (1.82 MB, application/zip)
2013-07-14 14:50 UTC, Bastián Díaz
Details
Comparison of presentation and outcome exported SVG (237.16 KB, image/png)
2013-07-15 11:10 UTC, Bastián Díaz
Details
Screenshot from LO 4.0.4.2 (177.68 KB, image/png)
2013-07-15 12:29 UTC, ign_christian
Details
SVG exports of slide 1 and 3 (from orig ODP) and some screenshots. (2.49 MB, application/zip)
2013-12-07 06:35 UTC, Owen Genat (retired)
Details
SVG from 6.3 a0 (661.68 KB, application/x-zip-compressed)
2018-12-11 18:49 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bastián Díaz 2013-07-14 14:50:50 UTC
Created attachment 82410 [details]
Examples of the problem.

Description of problem:
By including SVG images in a slideshow format and then export the slide vector format, the images change their appearance.(in some cases the image disappears)

Version-Release number of selected component (if applicable):
fedora 19
GNOME 3.8.3
LibreOffice 4.1.0.1 | 4.1.0.1-8.fc19 (default package in fedora)


How reproducible:
always

Steps to Reproduce:
1.create a presentation
2.include text and image in SVG format
3.Export presentation to SVG format.

Actual results:
The exported presentation shows the image in the presentation with another aspect

Expected results:
When exporting SVG format presentation, including images do not change their appearance.

Additional info:
I think this has to do with the way the image is SVG. I mean that in some cases the image within the file are a group of images, which in some cases or simply left free. A user does not verify this (eg with Inkscape) simply use the image as any.

See also:Bug 61314
See also:Bug 66900

Thanks
Comment 1 ign_christian 2013-07-15 02:14:07 UTC
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)
Comment 2 Bastián Díaz 2013-07-15 11:08:56 UTC
(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.
Comment 3 Bastián Díaz 2013-07-15 11:10:29 UTC
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.
Comment 4 ign_christian 2013-07-15 12:29:49 UTC
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.
Comment 5 Bastián Díaz 2013-07-15 14:06:19 UTC
(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.
Comment 6 ign_christian 2013-07-15 14:32:18 UTC
> 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.
Comment 7 Owen Genat (retired) 2013-12-07 06:35:20 UTC
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.
Comment 8 Owen Genat (retired) 2013-12-07 06:42:17 UTC
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.
Comment 9 Bastián Díaz 2013-12-07 18:44:42 UTC
(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.
Comment 10 QA Administrators 2015-04-19 03:20:24 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2015-06-15 11:40:41 UTC
(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)
Comment 12 QA Administrators 2016-09-20 10:00:55 UTC Comment hidden (obsolete)
Comment 13 Roman Kuznetsov 2018-12-11 18:47:23 UTC
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
Comment 14 Roman Kuznetsov 2018-12-11 18:49:06 UTC
Created attachment 147450 [details]
SVG from 6.3 a0