View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0011814||Scribus||Styles||public||2013-10-26 21:41||2019-08-05 08:48|
|Priority||high||Severity||crash||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0011814: Managing styles when pasting an object coming from another document|
|Description||When 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.
|related to||0002457||confirmed||Duplicate Styles from Scrapbook could be handled a bit more gracefully.|
|has duplicate||0014148||closed||JLuc||Pasting images from another Scribus project pastes and replaces the text styles in the target document|
|has duplicate||0015758||closed||jghali||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|
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.
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.
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).
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.
||a first step could be, to avoid checking and copying styles when no text is involved (as an example when copying an image frame)|
|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|