View Issue Details

IDProjectCategoryView StatusLast Update
0005190ScribusImport / Exportpublic2015-04-06 22:36
Reporteraxelb Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0005190: Export story text as something better than txt
DescriptionIf I save my text in the story editor I only have the possibility to save as txt, and that is highly insufficient as this not even saves my dashes (that gets replaced by ?), let alone more complicated things like nonbreakeable spaces (they just get replaces by _). I would suggest the odt-format, it is open, xml-based and should support just about everything needed. This way it would be possible to edit the text with another editor if you wish, even ease the processs of automation (search/replace, insert, editing). On slow machines this could really boost the performance and let you focus on the layout in Scribus. I think the saved format should support everything that Scribus can do with this text, at least:
* Remember wich styles are used
* Support all types of characters

The complicated things can then be remembered through the linked style, wether this is as a separate file or included.
Steps To Reproduce1. Open the story editor with you text
2. Use «Save» to save it
3. Open your saved file, it can only be txt
Additional InformationOf course I know you *ought* to finished the text editing in f.i. OOo before you import it, but the converion of the styles has its quircks, so you probably would have to edit the styles anyway. And it is just natural (ans expectable) that you would only spot what changes are needed after you see it all in the right context (with graphics and all). In short: This might be ideal, but hardly feasable for all cases.
TagsNo tags attached.
Patch

Relationships

has duplicate 0011261 closedjghali Export of text frame to *.odt collaboration with other humans without lose of formatting 
related to 0001394 acknowledged XML based editing 

Activities

avox

2007-01-18 11:49

administrator   ~0014857

1.3.4 will export dashes, smarthyphens and nonbreaking spaces as Unicode (it uses Unicode for those internally now)

Come to think of it, dashes should already be saved as Unicode. Do you look at the saved text with encoding set to UTF-8?

axelb

2007-01-18 12:05

reporter   ~0014858

Last edited: 2007-01-18 12:06

Good! I am eagerly awaiting a version of it that is production ready :-)

The file I got was appearantly not unicode, but iso-8859-1, trying to change the encoding to unicode (Kate) did not, apart from rendering also my norwegian characters as strange signs (question marks within circles), make any difference.

avox

2007-01-18 12:08

administrator   ~0014859

Scribus should export text as UTF-8 (or a user chosen encoding).

axelb

2007-01-21 21:23

reporter   ~0014930

"Scribus should export text as UTF-8 (or a user chosen encoding)."

Yes, my fault, I just used the standard. But the nonbreaking spaces are left as "_"s, don't know if they really work as they should, but, most important: All italics, bolds etc. are then lost, a loss wich makes out a big part of my text, this still means that the text needs much refinement to be usable in another context.
Would it be possible to save the style information with the text? Of course this would only be usable for Scribus, but still a good thing OMHO.

cbradney

2007-01-21 21:23

administrator   ~0014931

Export to text is export to text.. not a styled format.

axelb

2007-01-22 01:24

reporter   ~0014937

cbradney: Yes, that is clear :-)
But it would be easier to reuse the text if styling information was added too :-)
It is of course not critical because I can reuse from other scribus documents, but what if the standard odt could also be a DTP standard, perhaps even implemented by other DTP programs? Interoperability is a good thing IMHO :-)

ringerc

2007-01-22 03:03

reporter   ~0014938

---- re 0014858 ----
axelb:

When you changed the encoding in Kate, you were actually just telling Kate to load the file as if it were UTF-8. The file was iso-8859-1, so this forced Kate to misinterpret the file, resulting in the mangled characters. To actually change a file's encoding you must load it with the old encoding, then "save as" with the desired new encoding, allowing the text editor to properly convert the data.

This, however, won't add information that wasn't already there. Saving an iso-8859-1 encoded file as utf-8 doesn't add anything, it just changes how it's stored. If Scribus can export more info in a UTF-8 encoded file (because UTF-8 can represent characters that iso-8859-1 can't), then you must get Scribus to output UTF-8 initially, rather than converting it later.

---- re 014937 ----
axelb:

Unfortunately there is no widely used standard text format that can store all the information Scribus supports. Most formats just can't handle the various kerning and leading controls, let alone things like embedded objects. Also, formats that do support styled text tend to support styling options Scribus does *not* support (and in some cases never will), so you lose information going in both directions. Additionally, most of them are a right pain to work with.

One potentially really good solution might be to have a cut down & improved story editor that runs outside Scribus and loads text from the same internal XML format. This is a similar principle to that used by Adobe InCopy. It's been discussed before and I think there's a bug for it somewhere, but there just aren't the people to do it right now. It'd be a lot of work.

I'm sure everyone would be interested to hear if you do know of a suitable format that can reliably round-trip all styling information supported by Scribus. I would - the only ways I've seen it suggested so far involve "piggy-backing" the extra styling onto character and paragraph styles in ODT, so OO.o doesn't understand the extra formatting, but can usually edit the file without destroying it. Even that is a limited approach, quite fragile, and doesn't solve the problem of OO.o having formatting options not supported by Scribus.

axelb

2007-01-22 08:15

reporter   ~0014943

Last edited: 2007-01-29 15:07

ringerc: Yes, I have sorted out the UTF-8 part, so the text is there as text, my fault (as mentioned above). My next reply was just to explain why something more than just plain text would be usefull, but I understand this is not a bug report but a feature request :-)

Regarding odt: Since this is a open format, what about sending suggested improvments to the oasis committee?
http://opendocument.xml.org or
http://www.oasis-open.org/committees/join.php
http://www.odfalliance.org/join.php
may be a start. If Scribus would be able to join the group and participate I think this would mean less work than starting a whole new format for Scribus :-)
 
I dont' know about any other open formats (better than odt) that would fit Scribus.
Your mentioned approach seems like a way to go for me, but I am no expert :-)

ChameleonRedOne

2012-12-17 15:05

reporter   ~0029435

Currently is not possible to export formatting for future editing what make Scribus more similar to Latex than to Inkscape - it is not possible to improve graphics design and export it in one place - it make large project too complex to use Scribus.

Please consider adding such *.odt export option what could replace *.txt export.

ale

2012-12-18 08:21

manager   ~0029438

hi chamaleonredone,

once the epub export plugin i could consider also working on a general html export plugin and eventually an .odt export, too.

if you want to help out, you can get in touch with me (a.l.e@impagina.org) and we can look for a way how you can give a hand and define how the .odt export plugin should work.

ChameleonRedOne

2013-01-04 17:51

reporter   ~0029595

Hi, Ale

I could define some requirement to export I not sure when in Google Docs :)

I think we should split it into three levels - basic, medium, advanced - to complete each level in phases html and *.odt is required. Since Html is hardcore for many people and *.odt is easier.

I could define at first some use case than requirements since it is normal way of deriving useful requirements for user.

I think that the most important use case is to load text, change it in Scribus and export text with partial formatting - next level could be with styles or full formatting.

Import should be also revised since replacing bullets with '-' is not what is need :)

Issue History

Date Modified Username Field Change
2007-01-18 10:45 axelb New Issue
2007-01-18 11:49 avox Note Added: 0014857
2007-01-18 12:05 axelb Note Added: 0014858
2007-01-18 12:06 axelb Note Edited: 0014858
2007-01-18 12:08 avox Note Added: 0014859
2007-01-18 12:08 avox Status new => acknowledged
2007-01-21 21:23 axelb Note Added: 0014930
2007-01-21 21:23 cbradney Note Added: 0014931
2007-01-22 01:24 axelb Note Added: 0014937
2007-01-22 03:03 ringerc Note Added: 0014938
2007-01-22 08:15 axelb Note Added: 0014943
2007-01-22 10:26 axelb Note Edited: 0014943
2007-01-22 10:27 axelb Note Edited: 0014943
2007-01-22 10:28 axelb Note Edited: 0014943
2007-01-22 10:29 axelb Note Edited: 0014943
2007-01-29 15:07 axelb Note Edited: 0014943
2012-12-15 21:02 jghali Summary Export story editor text as something better than txt => Export story text as something better than txt
2012-12-15 21:03 jghali Relationship added has duplicate 0011261
2012-12-17 15:05 ChameleonRedOne Note Added: 0029435
2012-12-18 08:21 ale Note Added: 0029438
2013-01-04 17:51 ChameleonRedOne Note Added: 0029595
2015-04-06 22:36 Kunda Relationship added related to 0001394