Bug 61314 - Export to SVG ignores background color set via direct formatting
Summary: Export to SVG ignores background color set via direct formatting
Status: RESOLVED DUPLICATE of bug 115549
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: filter:svg
Depends on:
Blocks: Presentation-Export SVG-Save
  Show dependency treegraph
Reported: 2013-02-22 21:48 UTC by Bastián Díaz
Modified: 2023-11-07 00:05 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Screenshot of the master page (92.38 KB, image/png)
2013-02-22 21:48 UTC, Bastián Díaz
ZIP Archive with screenshots (230.79 KB, application/zip)
2013-02-22 22:06 UTC, Bastián Díaz
difficulties with SVG exported LO impress (51.92 KB, image/png)
2013-04-03 19:44 UTC, Bastián Díaz

Note You need to log in before you can comment on or make changes to this bug.
Description Bastián Díaz 2013-02-22 21:48:45 UTC
Created attachment 75376 [details]
Screenshot of the master page

Description of problem:
When attempting to export a presentation to the SVG format, the result differs from the original (color and font) in 3.6. But when trying to perform this operation on this LO 4.0 closes unexpectedly. I noticed that when exporting to that format, follows the guidelines of the master page and it looks like the current slide (attached ODP, PDF and SVG test presentation, also attached screenshot where it shows color master page).

Version-Release number of selected component:
Fedora 18 (Spherical Cow) 32-bit
GNOME 3.6.2
LO version (Build ID:
LO version (Build ID: a5acd33bc54cbc00f2194c923641fbd0ab45d80)

How reproducible:
1. Open a presentation (ODP) with LO Impress
2. Open file menu and select "Export"
3. Select and export SVG document
Actual results:
In LO 3.6, the export is performed without problems (current slide), but the results differ from the image of the slide.

In LO 4.0 to try to do this, the program closes unexpectedly.

Expected results:
That the export performance as faithful to the slide is displayed in LO Impress

Additional info:
I do not know the method of export to SVG using LO, however I have read that format and your chances are much broader.
With regard to the particular case, it would be ideal to embed the font used (or transform it into strokes).
I realized the mistake trying to pass some presentations (ODP) to SVG format and then create presentations Prezi style with Inkscape and Sozi plugin.
Comment 1 Bastián Díaz 2013-02-22 22:06:45 UTC
Created attachment 75377 [details]
ZIP Archive with screenshots

Attachment in the ZIP file
- Presentation ODP test
- Presentation in PDF
- Picture exported in SVG format
- Image Capture (error when exporting) as 4.0 on Windows

I can verify that there is a similar problem when exporting SVG format in LO 4.0 under Windows. Instead of closing as Linux, Windows reports an error writing.

Windows 7 PRO 32-bit
LO Version (ID de compilación: 7545bee9c2a0782548772a21bc84a9dcc583b89)

Comment 2 A (Andy) 2013-03-23 21:52:51 UTC
partly reproducible with LO (Win7 Home, 64bit)

The export functions works with Win7 without error message.
@Bastián: Does this issue still persists for you with the latest release of LO?

But, what I can confirm is that the exported slide is in yellow, while the presentation is in blue, which seems to be related to the Master Page settings.

@Radek: Could this maybe be something for you?
Comment 3 Bastián Díaz 2013-04-03 19:42:09 UTC
(In reply to comment #2)

> The export functions works with Win7 without error message.
> @Bastián: Does this issue still persists for you with the latest release of
> LO?

Indeed follow the same drawbacks in LO impress both Linux ( and Windows (Versión 84102822e3d61eb989ddd325abf1ac077904985).

Moreover, you can add some extra difficulty (see inkscape logo in attachment).
Comment 4 Bastián Díaz 2013-04-03 19:44:05 UTC
Created attachment 77389 [details]
difficulties with SVG exported LO impress

Beware inkscape logo and typography.
Comment 5 Bastián Díaz 2013-07-13 00:24:21 UTC
The problem persists in version libreoffice (Versión: - Id. de compilación: I do not see the error message, but the export does not work properly.

→ The background color does not appear in the exported version (usually export only typography and images on a transparent background)

→ You can only export a slide. When exporting multiple slides, they appear superimposed on a single image.

Would it be possible to improve export in SVG format?. I mean something similar to what happens to export to PDF (page) or grid view (single page) or files with layers (1 layer per slide). The idea is to reuse the SVG format display and use other tools (such as sozi with Inkscape plugin and make a Prezi stylish presentation).
Comment 6 ign_christian 2013-07-13 01:19:15 UTC
I can confirm same results as comment 1 with LO (Ubuntu 12.04 32bit). 

Export to PDF & SVG produce different background color.

Result on comment 4 not occured. If that occur with 4.0.1, I think that issue should be reported on different bug report.
Comment 7 ign_christian 2013-07-13 01:36:22 UTC
Tested on LO (Win7 32bit), I can reproduce behavior on comment 4.

@Bastián, I would suggest to open new bug report following this regression problem.
Comment 8 Bastián Díaz 2013-07-13 06:49:50 UTC
(In reply to comment #7)
> @Bastián, I would suggest to open new bug report following this regression
> problem.

Hi @ign_christian

Do not quite understand you need.

Do I have to open a new bug report the problem? or do you just need to open another bug report specifying the problem of comment 4?

Comment 9 ign_christian 2013-07-14 01:20:42 UTC
> Do I have to open a new bug report the problem? 
Yes please :)
Then you could link this bug report to the new report in section "See Also"

Hope that will help dev to track these issues
Comment 10 ign_christian 2013-07-14 02:29:10 UTC
Hi Bastián, I think issue on comment 4 is covered in Bug 60757. Please take a look at that.
Comment 11 ign_christian 2013-07-14 02:36:16 UTC
Sorry..not related. I forgot that's about export to svg :)
Comment 12 Owen Genat (retired) 2013-12-06 23:30:03 UTC
Summary amended to make it clearer what the problem reported in this bug is. The particular issue is as indicated in comment #2. The master page has a background color of "Chart 10" (#ff950e) i.e., in styles.xml:

> <style:style style:name="Default-background" style:family="presentation">
>    <style:graphic-properties draw:stroke="none" draw:fill="solid" draw:fill-color="#ff950e" draw:fill-image-width="0cm" draw:fill-image-height="0cm"/>
> <style:text-properties style:letter-kerning="true"/></style:style>

... while the slide in the presentation (attached in comment #1) uses "Sea blue" (#0066cc) i.e., in content.xml:

> <style:style style:name="dp1" style:family="drawing-page">
>    <style:drawing-page-properties presentation:background-visible="true" presentation:background-objects-visible="true" draw:fill="solid" draw:fill-color="#0066cc" draw:fill-image-width="0cm" draw:fill-image-height="0cm" presentation:display-footer="true" presentation:display-page-number="true" presentation:display-date-time="true"/>
> </style:style>

Export to SVG results in the graphic using "Chart 10" rather than "Sea blue". Any use of Format > Page... > Background tab on a slide appears to be ignored i.e., in this case if there was no associated master page then no page background color would be exported.
Comment 13 Owen Genat (retired) 2013-12-07 00:05:22 UTC
Behaviour reported in comment #12 has been tested under Ubuntu 10.04 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

In all cases the background colour of the master page is written out to the SVG rather than the background colour of the slide (direct formatting). Version set to Inherited From OOo.
Comment 14 Owen Genat (retired) 2013-12-08 04:43:28 UTC
*** Bug 66900 has been marked as a duplicate of this bug. ***
Comment 15 QA Administrators 2015-04-19 03:22:28 UTC Comment hidden (obsolete)
Comment 16 Buovjaga 2015-06-18 14:05:03 UTC
(In reply to Bastián Díaz from comment #1)
> Created attachment 75377 [details]
> ZIP Archive with screenshots

Now the svg export is even more broken: the mountaintop turns all square-y.

Win 7 Pro 64-bit Version:
Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56
Locale: fi-FI (fi_FI)
Comment 17 QA Administrators 2016-09-20 10:10:38 UTC Comment hidden (obsolete)
Comment 18 Regina Henschel 2017-12-05 13:42:21 UTC
The problem still exists in Version: (x64)
Build ID: 401a3d2336bf46b38235c498ff86ff675d0de759
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-11-28_00:13:08
Locale: de-DE (de_DE); Calc: CL
Comment 19 QA Administrators 2018-12-06 03:57:38 UTC Comment hidden (obsolete)
Comment 20 Roman Kuznetsov 2018-12-11 18:35:00 UTC
still repro with file ODP from attach in

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
Comment 21 QA Administrators 2020-12-11 03:47:21 UTC Comment hidden (obsolete)
Comment 22 QA Administrators 2022-12-12 03:18:20 UTC Comment hidden (obsolete)
Comment 23 Stéphane Guillou (stragu) 2023-11-07 00:05:47 UTC
Reproduced in:

Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

Fixed in:

Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

It was fixed for bug 115549, marking as duplicate.

*** This bug has been marked as a duplicate of bug 115549 ***