Bug 60814 - Colors of shapes change after copy+paste from one drawing to another
Summary: Colors of shapes change after copy+paste from one drawing to another
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: bibisected40
Keywords: bibisected, needsDevAdvice, regression
Depends on: 41436
Blocks: Paste
  Show dependency treegraph
 
Reported: 2013-02-13 19:08 UTC by Clemens Eisserer
Modified: 2023-02-04 19:13 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
testcase (9.65 KB, application/vnd.oasis.opendocument.graphics)
2013-02-13 19:08 UTC, Clemens Eisserer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Eisserer 2013-02-13 19:08:36 UTC
Created attachment 74776 [details]
testcase

When copying shapes from one drawing to another using the clipboard, colors of the shapes are changed as illustrated in the screencast: http://youtu.be/cT4xWtDoJVo

This happend on Fedora17+updates running XFCE.
Comment 1 Joel Madero 2013-02-23 21:28:16 UTC
Version: Version 4.1.0.0.alpha0+ (Build ID: 9601a571d42b0199bdccf2256fc8be82e14af8a)
Date:   Fri Feb 22 23:19:22 2013 +0200
Bodhi Linux 2.2

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

New (confirmed)
Major (loss of data)
Medium (default is high, downgraded to medium as there is an easy workaround just setting the color again)


regression


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bibisect
 5655f1571312ca27537c9c147c69d6431986b76d is the first bad commit
commit 5655f1571312ca27537c9c147c69d6431986b76d
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 08:13:31 2012 +0000

    source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
    
    commit b67a51b40a4876f4bd97a2917103112006710b0c
    Author:     Markus Maier <maier@fs.ei.tum.de>
    AuthorDate: Thu Nov 29 16:10:23 2012 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu Nov 29 17:35:25 2012 +0000
    
        add sort tab page .ui
    
        Change-Id: Ib5471b2a4cae45cf8aa32b438bac7f5cda35f71a

:100644 100644 7a4fdcf1d95f530a3149d02b8fe7971875973e76 42f18f15fb3370ca3f85d6a637b17ae05b10996f M	autogen.log
:100644 100644 5f05b5eaceb8a57fa910addc049fe1ff83b05b8a 820b9e1d79db3dba2880de552a311faa29bbf809 M	ccache.log
:100644 100644 613cffd64bfbd22a56a066164e70370f23603226 8a6e4f4cb7119b66a81a7c836167c86a3bc97882 M	commitmsg
:100644 100644 70bef30ec00af18be350b77f58e9c5bf02a109b4 2482442714ae1b18d33e19012abd7640f509afb4 M	dev-install.log
:100644 100644 709b8855043c670f0ccb34fe1427dccea58ff66a 95a1b31e755e1b56e4b0dc135d0b2769194481b9 M	make.log
:040000 040000 0e347c259b7b09c8cdb9b92ea62838dd657d0fb7 2ce4b89c04c797a3f31ec93b5ce499f4d0c9abd4 M	opt



# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect good 47498a36f7af8f54e6e3dda89cd4708802a409e6
# good: [66083171ba534818399937597388d325091fffab] source-hash-9d83ad0e99ab182506be99f7d6a2bec7f6fbe8c6
git bisect good 66083171ba534818399937597388d325091fffab
# bad: [8407d6926d9fa83ebbd8e03de319ea63df131753] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337
git bisect bad 8407d6926d9fa83ebbd8e03de319ea63df131753
# good: [ec7d01ea25190e36518df830ed84b791b2417e2e] source-hash-c33019b36d613f951787ce9836e34d74bfbd6a1b
git bisect good ec7d01ea25190e36518df830ed84b791b2417e2e
# bad: [5655f1571312ca27537c9c147c69d6431986b76d] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
git bisect bad 5655f1571312ca27537c9c147c69d6431986b76d
Comment 2 Joel Madero 2013-02-23 21:29:06 UTC
@Clemens - when you report bugs please (even for incredibly simple bugs) write out steps how to reproduce in an easy to read method, makes it much easier for QA to work and much easier for devs to see the issue.
Comment 3 Clemens Eisserer 2013-02-23 22:01:33 UTC
@Joel: Thats why I added the video. instead of complex textual description, its easily understandable what I did and what happend watching the video.
Previously I filed bugs with textual descriptions - which caused confusion. Textual description can be interpreted in many different ways...

Thanks for bisecting :)
Comment 4 CassieLX 2013-06-04 16:09:13 UTC
I can confim this on Libre Office V4.0.3.3.

The colours change between copying from one drawing and paste it into another one. I have to copy and paste a very big block diagram into a new form.
Unfortunately large parts of the drawing are change the color. Outline blue (!) and black to grey e.g.

Perhaps the fill color will be mixed with the line-colour? Wrong size/handling of the colourtable? Maybe this helps.
Comment 5 CassieLX 2013-06-04 20:26:59 UTC
Libre Office 3.6.6 is not affected by this bug. This is a regression between LibO 3.6 and 4.0.

One thing I have discovered:
After copy and paste in libO 4.0.x the color has changed. If I correct this manually and save the file, close LibO, reload the new saved drawing and copy and paste it into a new drawing the colors does NOT change anymore.

Is this a bug with the embedded color palette between different LibO-Series?
Comment 6 CassieLX 2013-06-04 20:59:35 UTC
The bug is also reproducable in Libre Office V4.1.0 beta 1.
Comment 7 David Tardon 2013-07-15 13:21:35 UTC
The regression here is because we have changed the default background color of a shape (from light blue to darker blue).

The underlying cause is that styles are matched only by name on pasting (at least in Draw/Impress. I am not sure how Writer handles it). Because every drawing has a style named Default, it is used even if it is not the same as the Default style in the the original drawing.

So, this is not really a regression, because it has always been broken. The brokenness is just more visible now.
Comment 8 David Tardon 2013-07-15 13:32:45 UTC
Actually this is only part of the picture. The second part, reported in bug#62175, is that custom styles are not copied with shapes, only with whole slides.
Comment 9 steve 2016-02-09 10:37:05 UTC
Retested, persisting. Adjusting hardware to all since reported on Linux and now reproduced on OSX.

Freeing bug since it has been assigned for over 2 years. David, retake if you still want to work on this.

Version: 5.2.0.0.alpha0+
Build ID: e07ffae5046e9c91ef96026435cab84c3bcb4534
CPU Threads: 4; OS Version: Mac OS X 10.11.3; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-02-08_23:39:45
Locale: de-DE (de.UTF-8)
Comment 10 Björn Michaelsen 2016-08-16 11:17:06 UTC
Adapt metadata:
Whiteboard:bibisected is Keyword:bibisected now.
Comment 12 Roman Kuznetsov 2018-06-17 12:57:52 UTC
still confirm for example from attach, but if i'm copying shape between two drawing in modern version of LO there isn't that problem.
Comment 13 QA Administrators 2019-06-18 02:47:13 UTC Comment hidden (obsolete)
Comment 14 Riyadh 2021-02-03 01:02:49 UTC
Writer DOES preserve the color! (see the informative comment 7 above)

Is it possible/appropriate to adapt the mechanism used in Writer to Impress?
Comment 15 Regina Henschel 2021-02-03 10:16:34 UTC
(In reply to Riyadh from comment #14)
> Writer DOES preserve the color! (see the informative comment 7 above)
> 
> Is it possible/appropriate to adapt the mechanism used in Writer to Impress?

Currently Writer does not support graphic styles at all. Therefore when pasting a drawing to Writer, the settings from the styles are "burned in" as direct attributes. Hopefully we will get graphic styles in Writer too so that this workaround can be removed.

I'm against "burn-in" as default behavior for Draw/Impress. For them graphic styles are essential. But I can image a "paste special" for to "burn-in" the values similar to Writer.
Comment 16 QA Administrators 2023-02-04 03:20:02 UTC Comment hidden (obsolete)
Comment 17 Clemens Eisserer 2023-02-04 19:13:40 UTC Comment hidden (no-value)