View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009598 | Scribus | Import / Export | public | 2010-12-19 21:48 | 2016-05-01 03:42 |
| Reporter | glanzel | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Intel PC | OS | Ubuntu | OS Version | 10.10 |
| Product Version | 1.3.9 | ||||
| Summary | 0009598: Styles don't get imported properly | ||||
| Description | If 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 Reproduce | create 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 Information | works in scribus 1.3.3 | ||||
| Tags | #pending, ODF | ||||
| Patch | No | ||||
| related to | 0013643 | assigned | fschmid | 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 |
|
|
Please provide sample OpenOffice document |
|
|
|
|
|
|
|
|
ok, 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. |
|
|
Would you confirm this is obsolete, as well ? Thanks! |
|
|
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. |
|
|
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? |
|
|
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 |
| 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 |
