Bug 80219 - FILESAVE: SVG loss some color after saving
Summary: FILESAVE: SVG loss some color after saving
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 102280 (view as bug list)
Depends on:
Blocks: SVG-Save
  Show dependency treegraph
Reported: 2014-06-19 08:50 UTC by vulcain
Modified: 2022-06-16 13:36 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

File for test (18.62 KB, application/vnd.oasis.opendocument.text)
2014-06-19 08:50 UTC, vulcain
Screenshot of expected saving's result (96.40 KB, image/png)
2014-06-19 09:18 UTC, vulcain
The bug (94.07 KB, image/png)
2014-06-19 09:19 UTC, vulcain

Note You need to log in before you can comment on or make changes to this bug.
Description vulcain 2014-06-19 08:50:02 UTC
Created attachment 101340 [details]
File for test

A french QA user give us his feedback: LibreOffice don't kee the SVG's color:

In LibreOffice Build ID: 881bb88abfe2992c6cede97c23e64a9885de87de on Ubuntu 12.04.4 x86_64

1) Open the attachement file defaut_couleur.odt
2) The two picture in the document are different
3) Rename the document defaut_couleur.odt as SVG_save.odt
4) Open SVG_save.odt
5) The two picture in the document are the same

Expected: after saving the two picture must be diffferents.
Comment 1 vulcain 2014-06-19 09:15:18 UTC
In french QA, the users reproduce in 
Windows 7/64 with:

Build ID: 881bb88abfe2992c6cede97c23e64a9885de87de

Build ID: a06aa316117a6ff0f05c697c82831c227812d810 

The bug is not reproduced in Ubuntu 12.04 x86-64 on LibreOffice
Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20 (fresh insatll) or LibreOffice Version ID : 350m1(Build:2)
Comment 2 vulcain 2014-06-19 09:18:50 UTC
Created attachment 101348 [details]
Screenshot of expected saving's result

The defaut_couleur.odt before saving: the two picture are different.
It's result expected
Comment 3 vulcain 2014-06-19 09:19:58 UTC
Created attachment 101349 [details]
The bug

The two picture are different after a saving and a new launch of the saved file
Comment 4 vulcain 2014-06-19 09:53:13 UTC
French QA user say that reproduce on Linux x86 => Platform x86_64 to all
Comment 5 Michael Stahl (allotropia) 2014-06-30 15:25:30 UTC
i take it the version was set in error? that one seems to work for me.

bug since 4.2.0 release
Comment 6 vulcain 2014-06-30 21:07:35 UTC
(In reply to comment #5)
> i take it the version was set in error? that one seems to work for
> me.

Yes, it's an error by me. In french's user, they always talk about a bug since 4.2.

Comment 7 Joel Madero 2014-07-08 16:53:07 UTC
Setting Priority:
Major - loss of data
High - Default seems appropriate

Unfortunately this bug is not really bibisectable, log below:

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# bad: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect bad c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# good: [1d4980621741d3050a5fe61b247c157d769988f2] source-hash-89d01a7d8028ddb765e02c116d202a2435894217
git bisect good 1d4980621741d3050a5fe61b247c157d769988f2
# skip: [89110ca258fa7a15dfc546acfb39e76fc3eb2a44] source-hash-e450a2c506ac7cd4433b0f93fc750a89919bc03c
git bisect skip 89110ca258fa7a15dfc546acfb39e76fc3eb2a44
# good: [1cca92a409385d9288c28a54d5e3008e56728bc0] source-hash-7be7824bbbdeee6fa998b950e6046ab37fe690cb
git bisect good 1cca92a409385d9288c28a54d5e3008e56728bc0
# skip: [5fa28ce2931a35ae64ae08d3904cfb76d24459d8] source-hash-2304beaca33c63b94df99cb827716f00ce259f9a
git bisect skip 5fa28ce2931a35ae64ae08d3904cfb76d24459d8
# good: [2a9ff869c5638dc5c3aa387d0fe55c3291c86288] source-hash-01b7e04172889cbc9e4ac404b105e18ddc062d6f
git bisect good 2a9ff869c5638dc5c3aa387d0fe55c3291c86288
# good: [387dd1052972d27a3065a249b357e50e0a29829b] source-hash-35836f350861b33a0c28307a413eff76d0433d1e
git bisect good 387dd1052972d27a3065a249b357e50e0a29829b
# bad: [09fe6d4400fefeaa099d0deb9b77c77992ab897b] source-hash-56364430108893afbcf5d2b51c5aaa37e393e7cc
git bisect bad 09fe6d4400fefeaa099d0deb9b77c77992ab897b
# good: [5c95a5c8caeeb347ef97f337a237d66c35261710] source-hash-a6d89e17995987549db36695f3ea490a18f30ba4
git bisect good 5c95a5c8caeeb347ef97f337a237d66c35261710
# bad: [4360256bc0b1443028a057164fbbdb43847ce68d] source-hash-40543e5321c8f618c125fd6f7f9a24b87431277a
git bisect bad 4360256bc0b1443028a057164fbbdb43847ce68d
# skip: [a66b45cf70625c9b4c0eb867530485b1319e2adb] source-hash-660800d6f33a01ad53fc0f5717e1c33868440d2f
git bisect skip a66b45cf70625c9b4c0eb867530485b1319e2adb
# only skipped commits left to test
# possible first bad commit: [4360256bc0b1443028a057164fbbdb43847ce68d] source-hash-40543e5321c8f618c125fd6f7f9a24b87431277a
# possible first bad commit: [a66b45cf70625c9b4c0eb867530485b1319e2adb] source-hash-660800d6f33a01ad53fc0f5717e1c33868440d2f
Comment 8 Matthew Francis 2015-02-14 01:02:13 UTC
Comment 7 is a perfectly good bibisect trace.
Setting -> Whiteboard:bibisected
Comment 9 Matthew Francis 2015-09-05 15:39:48 UTC
This seems to have changed at the below commit.
Adding Cc: to caolanm@redhat.com

    commit 223f6b631c1b087754c0f9051fb55f029f2503ce
    Author:     Armin Le Grand <alg@apache.org>
    AuthorDate: Tue Oct 29 14:11:45 2013 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu Oct 31 15:56:14 2013 +0000
        Resolves: #i123433# Detect pseudo-vertices at svg import...
        unify svg:d handling, correct svg:d import for relative sub-polygons in svg
        import; changed default for moveto writes for svg:d in ODF to absolute
        (cherry picked from commit f15874d8f976f3874bdbcb53429eeefa65c28841)
Comment 10 Robinson Tryon (qubit) 2015-12-13 11:11:01 UTC Comment hidden (obsolete)
Comment 11 Aron Budea 2016-09-22 03:49:47 UTC
*** Bug 102280 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2016-09-26 15:03:11 UTC
Adding Cc: to Armin Le Grand
Comment 13 tommy27 2016-10-13 03:54:09 UTC
bug persists in
Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02
Locale: it-IT (it_IT); Calc: group

did yo have time to look at this regression?
Comment 14 Roman Kuznetsov 2018-06-20 19:41:29 UTC
still repro in LO 6.1 beta 2
Comment 15 QA Administrators 2019-06-21 02:52:39 UTC Comment hidden (obsolete)
Comment 16 paulystefan 2020-03-10 20:56:25 UTC Comment hidden (obsolete)
Comment 17 paulystefan 2020-03-10 20:57:39 UTC Comment hidden (obsolete)
Comment 18 paulystefan 2020-06-20 20:08:05 UTC
no change in LO 7.0.0 beta2 x64 win10 x64
Comment 19 paulystefan 2020-06-20 20:08:19 UTC Comment hidden (obsolete)
Comment 20 BogdanB 2020-12-21 16:57:09 UTC
*** Bug 135642 has been marked as a duplicate of this bug. ***
Comment 21 paulystefan 2021-05-17 13:45:09 UTC
still, reproduce in 

Version: (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
Comment 22 paulystefan 2021-08-05 21:28:17 UTC
still, reproduce in 

Version: (x64) / LibreOffice Community
Build ID: 614be4f5c67816389257027dc5e56c801a547089
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
Comment 23 Jean-Baptiste Faure 2022-02-05 22:43:45 UTC
There is no svg in the test file.
From the discussion on the qa-fr mailing list (https://listarchives.libreoffice.org/fr/qa/2014/msg01217.html) it is clear that the image is a drawing in Draw format resulting from the import of an SVG image in Draw that has been converted in Draw format, then copied & pasted in the text document.

It is possible to play with the Draw object in Draw. There is several layers of grouped objects. Entering the group and moving some part of the group from front to back, allows to retrieve to correct color. Then saving et reloading the file keep the drawing unchanged. So I guess there is something wrong in the drawing object, and the bug was in the LO version which did the conversion SVG -> Draw object. 

As the original SVG file is not available, it is not possible to reproduce the path from the SVG to the drawing object in the text document. So I guess it is not possible to do something with this bug report.

Best regards. JBF
Comment 24 Jean-Baptiste Faure 2022-02-08 18:13:07 UTC
I have the feeling that the situation that produces the test file was itself a bug concerning SVG files and that this bug has been fixed (some work has been done on the SVG import) and that now it is not possible to reproduce the test file with recent versions.

So I close this bug report as WontFix. Feel free to reopen if you disagree and have a mean to reproduce the test file using a SVG image.

Best regards. JBF
Comment 25 paulystefan 2022-06-16 13:36:38 UTC
Bug is still active.

Dark blue icon goes to blue icon like second.

Version: (x64) / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL