View Issue Details

IDProjectCategoryView StatusLast Update
0009598ScribusImport / Exportpublic2016-05-01 03:42
Reporterglanzel Assigned To 
Status newResolutionopen 
PlatformIntel PCOSUbuntuOS Version10.10
Product Version1.3.9 
Summary0009598: Styles don't get imported properly
DescriptionIf i import a Document from OpenOffice Scribus shows the Name of
the imported Style.
If you change this style the changes are only shown in the beginning a of the text. everything after the occurence of the first umlaut mark or after the first paragraph remains the same.
Steps To Reproducecreate an document with open office write, with 2 or more paragraphs and one umlaut mark and with one style.
import this text in scribus (no checkboxes selected in the import dialog). change the style of the text.
Additional Informationworks in scribus 1.3.3
Tags#pending, ODF


related to 0013643 assignedfschmid Return of the Style import features for text (but this time better) 
related to 0008024 acknowledged More intelligent handling of imported styles 
related to 0011420 confirmed 1.5 style management during page import 
related to 0011814 confirmed Managing styles when pasting an object coming from another document 



2010-12-19 22:33

administrator   ~0025162

Please provide sample OpenOffice document


2010-12-20 11:51



2010-12-20 11:52


scribus_style_test.odt (11,855 bytes)


2010-12-20 11:58

reporter   ~0025165

Last edited: 2011-01-05 23:18


i attached 2 files.
i took a look inside scribus file too.
it looks like the problem when importing more than one paragraph is the following:
for the 1 paragraph only the style is defined
for the 2 and all other paragraph additional some attributes of the original text are defined for example the font and fontsize, these attributes seems to overwrite the style attributes.


2016-04-26 22:56

updater   ~0040526

Would you confirm this is obsolete, as well ? Thanks!


2016-04-28 04:22

reporter   ~0040563

Bug is obsolete.

Given ODT text with a user-defined style applied to it, Glanzel reports that when that text is imported along with its user-defined style, modifications to that user-defined style only change the appearance of the first paragraph. This is not true of the current importer. Now NONE of the paragraphs respond to changes in the style. At least it's consistent.

Glanzel's ticket shows an understanding of the cause. A paragraph can have its appearance impacted by a user-defined style, by direct formatting, or a combination of the two. When a paragraph that is subject to a named style has direct formatting applied to it, those settings become exceptions to the named style on that paragraph and they no longer change when the named style is modified.

During ODT import, the user-defined style is brought in, the text is brought in, and it's appearance is applied as direct formatting, even if OpenOffice had considered that formatting to be caused by the user-defined style. Therefore, within imported text, everything is an exception and nothing is "caused" by, or beholden to, the user-defined style, even if its appearance is identical.

The workaround is simple. Either reapply the user-defined style to the text, or use the trash can icon next to the style name in the properties window to remove the direct formatting. Both approaches re-establish the user-defined style's control over the paragraph.

Glanzel's ticket further reports that in terms of the above, some special characters, e.g. the umlaut, have the same effect as starting a new paragraph. Modern Scribus doesn't seem influenced in any way by such characters.


2016-04-28 16:30

updater   ~0040583

Thanks Ben for the attention. Appreciate the elaboration.

> Now NONE of the paragraphs respond to changes in the style. At least it's consistent.
Here you imply that Scribus should respond to the change in all the paragraphs instead of none?


2016-04-30 23:35

reporter   ~0040659

Last edited: 2016-05-01 03:42

The ticket originator, glanzel, certainly expected that. He was trying to use it that way and had difficulty, which he reported. I believe that Scribus should be able to accommodate that use case. My own use case, detailed in 0013643:0038898, is closest to extreme case 2, below, but I'm trying to be unbiased in this ticket.

Thanks partly to its price, Scribus can be expected to have a broad user base with varying expectations of how Scribus should handle the styles contained in imported content. At the moment, Scribus isn't well equipped to discern these expectations (tickets 0013643, 0008024, 0011420, 0011814).

Extreme Case 1: The church secretary has almost finished a mailing in a word processor before importing it into Scribus. The entire document has the style "Default Style" but direct formatting has been repeatedly applied throughout to make it look and fit exactly as desired. To her, user-defined styles are irrelevant and she wants scribus to respect all of her direct formatting. She will further tweak this formatting within scribus to finish her project.

Extreme Case 2—Paragraph Styles as paragraph "type" declarations: A school secretary is assembling the quarterly newsletter from articles that each teacher e-mailed. The secretary wants scribus to automatically unify the appearance of the newsletter, enforcing the academy standard of "Comic Sans" for all paragraphs with the style "Body Text" and overriding any individual teacher's choice of Times New Roman. She will tweak style definitions in scribus to make things fit on the page while maintaining uniformity, and expects all paragraphs with the matching style to obey in unison.

Middle Case: The user wants to import a document and resume where the word processor left off. The user wants Scribus to import the styles, the content, and any direct formatting. Scribus is expected to understand where direct formatting is overriding a style to provide an exception and where the content should remain responsive to changes in the style.

Glanzel appears to be in one of the latter two camps; the current ODT importer seems most accommodating to the first. The workarounds I mentioned allow the user to remove direct formatting from all imported content (enabling extreme case 2) or from part of it (enabling the Middle case, but not at all automatically).

In any event, I'm confident that the importers are a work in progress that will someday address this and there are two workarounds available for glanzel in the meantime. I do think that consistent and understandable software behavior with available workarounds is preferable to the (now fixed) inconsistent results that glanzel reported.

Suggested relationship: I suspect that the 3 cases I just mentioned are also responsive to ale's request in 0013643:0038901

Issue History

Date Modified Username Field Change
2010-12-19 21:48 glanzel New Issue
2010-12-19 22:33 jghali Note Added: 0025162
2010-12-20 11:51 glanzel File Added: scribus_style_test2.odt
2010-12-20 11:52 glanzel File Added: scribus_style_test.odt
2010-12-20 11:58 glanzel Note Added: 0025165
2011-01-05 23:18 glanzel Note Edited: 0025165
2016-04-26 22:56 Kunda Note Added: 0040526
2016-04-28 04:22 Ben Note Added: 0040563
2016-04-28 16:30 Kunda Note Added: 0040583
2016-04-28 16:30 Kunda Patch => No
2016-04-28 16:30 Kunda Severity major => minor
2016-04-28 16:30 Kunda Tag Attached: #pending
2016-04-28 16:30 Kunda Tag Attached: ODF
2016-04-30 23:35 Ben Note Added: 0040659
2016-04-30 23:37 Ben Note Edited: 0040659
2016-04-30 23:42 Kunda Relationship added related to 0013643
2016-04-30 23:42 Kunda Relationship added related to 0008024
2016-04-30 23:42 Kunda Relationship added related to 0011420
2016-04-30 23:42 Kunda Relationship added related to 0011814
2016-04-30 23:42 Kunda Note Edited: 0040659
2016-04-30 23:43 Kunda Note Edited: 0040659
2016-05-01 03:42 Ben Note Edited: 0040659