View Issue Details

IDProjectCategoryView StatusLast Update
0011420ScribusImport / Exportpublic2019-11-14 14:54
ReporterJLuc Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status confirmedResolutionopen 
Product Version1.5.0svn 
Target VersionFixed in Version 
Summary0011420: 1.5 style management during page import
Description[EDIT] The same issue exists when
- copying an object in a document and paste it in another document
- placing an object in the scrapbook and paste it in another document
- importing some page(s) from some other document (0011814)

1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.
Additional Information- When testing the uploaded docs you'll notice that the import does not position the imported content at its right place : that's 0011411

- this issue was reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778 [^]
TagsMABs, styles
PatchNo

Relationships

related to 0011814 confirmed Managing styles when pasting an object coming from another document 
related to 0007359 confirmed Appending text with styles uses incorrect formatting 
related to 0002457 confirmed Duplicate Styles from Scrapbook could be handled a bit more gracefully. 
related to 0009598 new Styles don't get imported properly 
related to 0009464 new Text formatting changes itself 
related to 0011111 new Style managing when importing pages 
related to 0015851 new Importing character style doesnt import character style 

Activities

JLuc

2013-02-13 19:32

developer  

pageimport.sla (26,698 bytes)

JLuc

2013-02-13 19:34

developer  

originating.png (202,730 bytes)
originating.png (202,730 bytes)

JLuc

2013-02-13 19:34

developer  

once imported.png (185,960 bytes)
once imported.png (185,960 bytes)

JLuc

2013-02-13 20:02

developer   ~0029837

2nd paragraph should read

- A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is NOT correct.

JLuc

2013-05-07 19:56

developer   ~0030133

At the end of a magazine creation session, requiring quite a few page-import actions (and maybe a couple of style-import actions too), the SLA is crippled with lots of "Copy of Suchstyle" and "Copy of Copy of Suchstyle". There even is a "Copie de Suchstyle (2)" which is its french counterpart. The "(2)" there is quite mysterious since there is no "Copie de Suchstyle" at all without the (2).

After researching in the SLA it appears that these "Copy of" styles are not used at all. So AFAIAC it's possible to delete them and it's quite easy to do so in editing the SLA with a text editor. Better would be not to create them, and even better would be to handle styles correctly during page or style imports.

JLuc

2013-06-05 15:43

developer   ~0030244

Last edited: 2013-06-06 05:08

View 3 revisions

Right now another experience :

I import various document using the same styles at the end of a document : the styles are not duplicated in the resulting merged document and everything looks allmost fine.
(But then, since no new style is created, a layout problem would have occured, in case the styles had had the same name but a different definition ???)

However, there seem to be a problem with interline space : when it has been changed localy, that change is not reported in the imported pages (the style default value used).
Importing another document's pages rises another issue : some characters become "bad glyph" squares...

JLuc

2015-01-05 10:00

developer   ~0034350

Last edited: 2015-01-05 10:01

View 2 revisions

A first management of this issue would be to plainly check, at the begining, whether there is a style conflict (= a style with the same name but with different properties in each of the SLA files). In case of such a conflict, scribus would display a detailed warning "There is a conflict with the style NAMEOFSTYLE" and basicaly enable to choose "Abort" or "Proceed".

Smarter action options could later be "Abort", "Overwrite existing style", "Keep existing style", "Rename imported style".

Smarter warning message would display the style differences : "Space after paragraph : 2pt (existing) / 0pt (imported) ; color : blue (existing) / darkblue (imported) ..."

Kunda

2015-05-14 14:37

manager   ~0035127

Think we should confirm this bug and set it for 1.5.1

JLuc

2015-10-16 12:58

developer   ~0036683

Last edited: 2015-10-16 12:58

View 2 revisions

Also reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778

JLuc

2015-10-16 13:00

developer   ~0036684

The same issue exists when
- copy an object in a document and paste it in another document
- place an object in the scrapbook and paste it in another document

Issue History

Date Modified Username Field Change
2013-02-13 19:31 JLuc New Issue
2013-02-13 19:32 JLuc File Added: pageimport.sla
2013-02-13 19:34 JLuc File Added: originating.png
2013-02-13 19:34 JLuc File Added: once imported.png
2013-02-13 20:02 JLuc Note Added: 0029837
2013-05-07 19:56 JLuc Note Added: 0030133
2013-06-05 15:43 JLuc Note Added: 0030244
2013-06-06 05:07 JLuc Note Edited: 0030244 View Revisions
2013-06-06 05:08 JLuc Note Edited: 0030244 View Revisions
2014-03-23 10:11 JLuc Tag Attached: foundation
2014-03-23 10:11 JLuc Tag Attached: style
2014-10-08 23:21 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:28 Kunda Tag Attached: MABs
2014-12-24 16:47 JLuc Patch => No
2014-12-24 16:47 JLuc Priority normal => high
2015-01-05 10:00 JLuc Note Added: 0034350
2015-01-05 10:01 JLuc Note Edited: 0034350 View Revisions
2015-05-14 14:37 Kunda Note Added: 0035127
2015-10-16 12:58 JLuc Note Added: 0036683
2015-10-16 12:58 JLuc Assigned To => JLuc
2015-10-16 12:58 JLuc Status new => confirmed
2015-10-16 12:58 JLuc Note Edited: 0036683 View Revisions
2015-10-16 13:00 JLuc Note Added: 0036684
2015-10-16 13:15 JLuc Assigned To JLuc =>
2015-10-16 15:06 JLuc Description Updated View Revisions
2015-10-16 15:06 JLuc Additional Information Updated View Revisions
2015-10-30 18:40 JLuc Description Updated View Revisions
2015-10-30 18:41 JLuc Relationship added related to 0011814
2015-10-30 18:42 JLuc Description Updated View Revisions
2015-10-30 18:42 JLuc Additional Information Updated View Revisions
2016-01-19 02:45 Kunda Relationship added related to 0007359
2016-04-04 09:28 JLuc Relationship added related to 0002457
2016-04-30 23:42 Kunda Relationship added related to 0009598
2016-05-09 15:17 Kunda Relationship added related to 0009464
2019-11-14 14:53 JLuc Relationship added related to 0011111
2019-11-14 14:54 JLuc Relationship added related to 0015851