View Issue Details

IDProjectCategoryView StatusLast Update
0011814ScribusStylespublic2019-08-05 08:48
ReporterJLuc Assigned To 
PriorityhighSeveritycrashReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version1.5.0svn 
Target VersionFixed in Version 
Summary0011814: Managing styles when pasting an object coming from another document
DescriptionWhen pasting an object coming from another document, all styles of the origin document are pasted in the destination document aswell, with no further ado.
If an existing style has the same name, it is overwriten without consent.

Sribus should detect that one of the imported style exists in the destination document and in such a case, it should ensure no design desaster happens.
It should compare the 2 versions of the styles
- In case they are different, it could display the differences found and should ask whether to overwrite the existing style or rename the imported style and, at least, it should ask whether to proceed or not.
- In case the 2 versions are the same, its not necessary to ask and import can proceed.

+ It should only import styles that are really in use in the imported document, since all other are not relevant. This would lighten the duty to ask how to manage conflicts.
TagsMABs, styles
PatchNo

Relationships

related to 0002457 confirmed Duplicate Styles from Scrapbook could be handled a bit more gracefully. 
has duplicate 0014148 closedJLuc Pasting images from another Scribus project pastes and replaces the text styles in the target document 
has duplicate 0015758 closedjghali Copy & Paste across different documents affects Styles 
related to 0011420 confirmed 1.5 style management during page import 
related to 0005320 confirmed Copy/Paste between docs may create unneccessary line styles 
related to 0009598 new Styles don't get imported properly 
related to 0009464 new Text formatting changes itself 

Activities

JLuc

2014-06-26 14:23

developer   ~0032321

Last edited: 2017-10-09 07:44

View 8 revisions

Same happens when inserting an item of the scrapbook.

When adding an item to the scrapbook, it looks like all styles of the current document are copied in the item's definition in the scrapbook,
and when using an item of the scrapbook in a new document, all styles of the originating document are pasted also and overwrite current local versions of current document :-( with no warning.

Scribus should (available choices at different actions ) :

When recording a new item in the scrapbook :
-A only record in scrapbook the styles that are really used by the item. It would clean the scrapbook.
-B ? when recording an item in the scrapbook rename styles with a uniqid prefix so they never interfere with future destination document. ?
This would immediately fix this bug, but would restrict the versatility of the scrapbook use since the only following option c) would be available.

When pasting an item from the scrapbook (in case the item styles have been recorded without the uniquid prefix that prevents conflicts) :
-C detect whether a style of the item also exists in the destination document
-D in such a case, ask for each conflicting style, whether the pasting action should either :
--*a) overwrite the allready existing style,
--*b) use the allready existing style
--*c) rename the pasted style so both item-style and document style exist and dont conflict

I've given names ABCD and abc to the propositions so they can be discussed and maybe coded separately. Please tell your mind.

ale

2016-06-13 16:00

manager   ~0041654

the current implementation is for sure the worst possible one.

i think that scribus should have a sane behavior and avoid asking the user about what to do (do not make the her slower && do not ask questions the user has a hard time to answer).

a sane behavior might be:

- only apply styles if the style exists in the target document (and apply them in the way they are defined in the target; by name); apply local formatting if it does not match the target style.
- if the style does not exist, apply the target's default style and apply the source style as local formatting.

on top of it, it should be possible to allow for more control in the scrapbook. we could have some advanced properties in there that define rules for the "transfer" of formatting.

in that way, copy paste is a fast and painless way to bring over content and the scrapbook allows a more advanced sharing of widgets.

JLuc

2017-10-08 09:28

developer   ~0044509

Last edited: 2017-10-08 12:31

View 2 revisions

Martin Z. wrote on the list :
> Yesterday, rather late, Scribus has tricked me. I had copied and pasted
> one small text-frame from another Scribus document and it destroyed my
> crossword-grid (same page, different layer, different style). Luckily I
> had zoomed so, that I caught it right away. (probably a bug, something
> to do with default-styles or whatever).

Luna Nightshade

2017-12-01 09:07

reporter   ~0044693

I have encountered this issue, too, but found a way to work around it for me:
After pasting such an object, import the style from the saved document, and replace the style with the original again.

ale

2018-03-05 15:54

manager   ~0045018

a first step could be, to avoid checking and copying styles when no text is involved (as an example when copying an image frame)

Issue History

Date Modified Username Field Change
2013-10-26 21:41 JLuc New Issue
2014-02-18 20:19 JLuc Tag Attached: #style
2014-02-18 20:19 JLuc Tag Attached: #styles
2014-03-23 10:10 JLuc Tag Attached: foundation
2014-03-23 10:10 JLuc Tag Detached: #styles
2014-03-23 10:10 JLuc Tag Detached: #style
2014-03-23 10:10 JLuc Tag Attached: style
2014-06-26 14:23 JLuc Note Added: 0032321
2014-06-26 14:23 JLuc Note Edited: 0032321 View Revisions
2014-06-26 14:24 JLuc Note Edited: 0032321 View Revisions
2014-06-26 14:27 JLuc Note Edited: 0032321 View Revisions
2014-06-26 14:27 JLuc Note Edited: 0032321 View Revisions
2014-06-26 14:28 JLuc Note Edited: 0032321 View Revisions
2014-10-08 23:22 Kunda Tag Attached: styles
2014-10-08 23:22 Kunda Tag Detached: style
2014-10-11 15:32 Kunda Tag Detached: foundation
2014-11-06 19:27 Kunda Tag Attached: MABs
2014-12-24 16:47 JLuc Patch => No
2014-12-24 16:47 JLuc Priority normal => high
2014-12-24 16:47 JLuc Severity minor => crash
2015-10-30 18:41 JLuc Relationship added related to 0011420
2016-04-04 09:30 JLuc Relationship added related to 0002457
2016-04-14 21:13 JLuc Relationship added related to 0005320
2016-04-30 23:42 Kunda Relationship added related to 0009598
2016-05-09 15:17 Kunda Relationship added related to 0009464
2016-06-13 07:16 JLuc Relationship added has duplicate 0014148
2016-06-13 07:19 JLuc Assigned To => JLuc
2016-06-13 07:19 JLuc Status new => confirmed
2016-06-13 07:24 JLuc Assigned To JLuc =>
2016-06-13 16:00 ale Note Added: 0041654
2017-10-08 09:28 JLuc Note Added: 0044509
2017-10-08 12:31 JLuc Note Edited: 0044509 View Revisions
2017-10-09 07:34 JLuc Description Updated View Revisions
2017-10-09 07:36 JLuc Description Updated View Revisions
2017-10-09 07:40 JLuc Description Updated View Revisions
2017-10-09 07:41 JLuc Description Updated View Revisions
2017-10-09 07:42 JLuc Note Edited: 0032321 View Revisions
2017-10-09 07:44 JLuc Note Edited: 0032321 View Revisions
2017-12-01 09:07 Luna Nightshade Note Added: 0044693
2018-02-14 11:21 jghali Relationship added has duplicate 0015146
2018-02-14 11:22 jghali Relationship deleted has duplicate 0015146
2018-03-05 15:54 ale Note Added: 0045018
2019-08-05 08:48 jghali Relationship added has duplicate 0015758