Created attachment 101340 [details] File for test A french QA user give us his feedback: LibreOffice don't kee the SVG's color: http://nabble.documentfoundation.org/perte-de-couleur-sur-svg-avec-Loo-4-2-td4112370.html In LibreOffice 4.2.5.1 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.
In french QA, the users reproduce in Windows 7/64 with: Version: 4.2.5.1 Build ID: 881bb88abfe2992c6cede97c23e64a9885de87de Version: 4.3.0.0.beta2 Build ID: a06aa316117a6ff0f05c697c82831c227812d810 The bug is not reproduced in Ubuntu 12.04 x86-64 on LibreOffice 4.1.5.1 Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20 (fresh insatll) or LibreOffice 3.5.7.2 Version ID : 350m1(Build:2)
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
Created attachment 101349 [details] The bug The two picture are different after a saving and a new launch of the saved file
French QA user say that reproduce on Linux x86 => Platform x86_64 to all
i take it the version 4.1.5.1 was set in error? that one seems to work for me. bug since 4.2.0 release
(In reply to comment #5) > i take it the version 4.1.5.1 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. Sorry
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 7 is a perfectly good bibisect trace. Setting -> Whiteboard:bibisected
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)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
*** Bug 102280 has been marked as a duplicate of this bug. ***
Adding Cc: to Armin Le Grand
bug persists in 5.3.0.0.alpha0+ 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 @Armid did yo have time to look at this regression?
still repro in LO 6.1 beta 2
Dear vulcain, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
not solved in LO 6.4.1.2 x64 in win 10-64
no change in LO 7.0.0 beta2 x64 win10 x64
*** Bug 135642 has been marked as a duplicate of this bug. ***
still, reproduce in Version: 7.1.3.2 (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
still, reproduce in Version: 7.2.0.2 (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
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
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
Bug is still active. Dark blue icon goes to blue icon like second. Version: 7.3.4.2 (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