View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013643||Scribus||Import / Export||public||2016-01-11 06:13||2016-05-09 15:17|
|Platform||x86_64||OS||OpenSUSE 64 Bit||OS Version||13.1|
|Target Version||Fixed in Version|
|Summary||0013643: Return of the Style import features for text (but this time better)|
|Description||As of the rewrite of the ODT importer, the import options for text styles have disappeared.|
I suggest we bring them back, but this time in a more useful manner.
In 1.4.x, the ODT importer offered a dialogue with the following checkboxes
 Overwrite Paragraph Styles
 Merge Paragraph Styles
 Use document name as a prefix for paragraph styles
 Do not ask again
By contrast, 1.5.1 has removed these options completely, and we now have the option to either append the name of the respective text frame or not.
Neither of both is satisfying.
As for the old ODT dialogue, we should retain the option to overwrite paragraph styles with the additional option to overwrite character styles.
Merging paragraph styles is dangerous, especially when character styles are also concerned, so it should either be removed or come with a big warning attached.
Document name or text frame name should both be options.
The "Do not ask again" option was always dangerous, because users had to edit a configuration file to get rid of the option.
Solution: Move all of those options to a new "Styles" tab in DocSetup/Prefs and make the "Do not ask again" choice a document-based feature.
As for the UI, I like that Franz has moved the new 1.5.1 option to the file dialogue. The rest could also be placed there (cf. LibreOffice or Illustrator).
|Tags||No tags attached.|
I have to second this request, since my way of using the importer didn't survive the rewrite.
My goal is to use OpenOffice (OO) as a powerful and convenient external "story editor" and its files as a portable exchange medium for version-controlled collaboration, peer review, proofreading, and translation. OO would handle the content and structure (via user-defined styles) and Scribus would handle final appearance. In this world, the same user-defined style names would exist in both OO and Scribus, but the appearance of the styles in OO would be optimized for proofreading and collaboration, while the appearance in Scribus would be that of the final product. It would also be nice to have user-defined character styles applied and checked for correctness in OO, long before the content hits Scribus. Import of user-defined character styles may make this possible in the future.
Part of this workflow stems from the fact that a Scribus document really wants to be one entity, not a tree-like structure of sub-files that lend themselves to collaboration, non-fixed page-counts, and integration into the whole as they become ready or are updated.
For a new interface, I like the idea of self-documenting radio buttons rather than checkboxes that override unseen defaults. Here's the most complex approach I can reasonably envision, leaving room for moderation by horrified coders:
Appearance of Imported Text:
o Match the look of the input file
o Use Scribus styles and defaults
o Import as raw text and apply paragraph style: [ Default Paragraph Style (drop-down) ]
New User-defined Styles within the Imported File:
o Create New Scribus Styles to match those in imported file
[ ] Prefix new style names with the name of this text frame
o Warn Me First and Allow me to Choose an Existing Style
Existing Scribus Styles Used by All Text Frames in This Document:
[ ] Change the Look of Existing Scribus Styles to match incoming styles
Problem: If you choose "Import Raw Text" in the first radio button set, how much of the rest makes sense?
You could put "Import Text Only" on the first (file-finding) dialog, always applying "Default Paragraph Style" if it's checked and have everything else on a popup that only appears if "Immport Text Only" isn't selected.
Current behavior is 1a, 2a with bonus checkbox, 3yes.
I'd prefer defaults that don't have document-wide impacts resulting from an import into one text frame. Perhaps: Match the look of the input file, Warn Me First and Allow me to Choose an Existing Style, change existing NOT selected.
If chosen, the The "warn me first" option could pop up a dialog allowing the user to name each new style (default=incoming name) or use a drop-down of existing styles for a style-mapping like mentioned in ticket 0010107
personally, i've always felt that the options for the importing where barely usable...
can we try to design a few useful options, based on real use cases / workflows rather than just replicate the options in 1.4.x?
anyway, i agree that prepending the text frame name is probably rather useless...
||Suggested relationship: 0008024|
||ale, I agree with you that style import could be handled better, but I'd expect some suggestions as to how it can be improved.|
|2016-01-11 06:13||christoph_s||New Issue|
|2016-02-25 06:09||Ben||Note Added: 0038898|
|2016-02-25 08:19||christoph_s||Assigned To||=> fschmid|
|2016-02-25 08:19||christoph_s||Status||new => assigned|
|2016-02-25 09:11||ale||Note Added: 0038901|
|2016-04-28 04:55||Ben||Note Added: 0040565|
|2016-04-28 07:12||christoph_s||Note Added: 0040566|
|2016-04-30 23:42||Kunda||Relationship added||related to 0009598|
|2016-05-02 15:48||Kunda||Relationship added||related to 0009858|
|2016-05-09 15:17||Kunda||Relationship added||related to 0009464|