View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001791 | Scribus | Story Editor / Text Frames | public | 2005-03-18 23:01 | 2018-03-24 08:27 |
| Reporter | pdonis | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | 1.3 | ||||
| Summary | 0001791: Linking to external text | ||||
| Description | There doesn't seem to be a way to link a text frame (or series of linked frames) in Scribus to an external text document, so that changes in the external document will automatically be detected by Scribus--in other DTP programs this can be done and if the external file has been changed, a dialog will automatically pop up when the document is opened asking if the linked text should be updated. As far as I can tell, if you've inserted text from an external document, the only way to update it if the external document changes is by doing "Get Text" again by hand. | ||||
| Steps To Reproduce | Create a new document, add a text frame, get text from external file, save and close. Change the external file; Scribus doesn't detect the change or update the text frame to reflect it unless you "Get Text" again. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
| related to | 0000111 | closed | cbradney | Scribus Document File format |
| related to | 0001394 | acknowledged | XML based editing | |
| related to | 0001925 | acknowledged | Multiple users sharing one open document | |
| related to | 0002108 | acknowledged | External copy editor tool | |
| related to | 0001132 | acknowledged | Styles should be separate from documents | |
| related to | 0010651 | new | Link text frame to SLA file |
|
|
That's right. The issue is with formatting. When the text was updated, you'd hardly want Scribus to automatically erase all your formatting, hyphenation fixes, etc. Thus it needs to attempt to merge them - and that's *really* rather hard. It's something I think is really interesting, especially from a perspective of supporting WebDAV access to content management systems etc. I'm just not sure how to do it. |
|
|
I agree that if you've changed the formatting within Scribus, you wouldn't want it clobbered when the text was updated. However, what if you're doing all the formatting in the external program that generates the text file you're importing? For example, what if you generate the external text document in OpenOffice, define all your formatting and styles there, and then just have Scribus import them along with the text? In that case you could safely erase and re-import the formatting along with the text (the hyphenation might still be a little gnarly, depending on how well automatic hyphenation on import suited your needs). There would probably still need to be some kind of prompt to the user to make sure that updating the formatting with the text was OK, but if the answer to that was "yes", then it would be a lot easier than having to merge it. |
|
|
True. My concern is with Scribus-specific formatting such as kerning adjustments, additional hyphenations, etc that most likely will not be present in the input text - and probably cannot even be expressed in its format. Separately to that, I do agree that the ability to update text would be useful even if formatting done in Scribus was discarded. |
|
|
For the kind of layout I'm talking about I would not expect to have to do any Scribus-specific formatting. I agree that there's no way to capture that in the input text, and certainly no obvious way to merge it with a modified input text (since the Scribus-specific adjustments were probably based on the specific positions of certain things on certain pages, which will change when the input text is modified). |
|
|
Sorry to step late in the conversation. :) I am not aware Quark keeps any link with any text file once the text is imported. What Quark can do is synchronizing text within a project. That is, changes in one text frame will reflect in other text frames if these frames are synchronized. InDesign can keep track of an Excel file. Don't know if they got into Word files yet. * * * The formatting issue is major imo because DTP apps have far more controls over type than WP apps and/or they handle the features differently. Of course, like you say, one can always get away with it by keeping the formatting to the most basic. But that could rapidly prove to be a drawback. And then comes the layout adjustments... The feature you're talking about could be helpful in some very tight environment where everybody knows what he's doing and what the other are doing. I dream of that! Now, let's face it! Would the feature be available I'd be the last to tell my clients. It's already fastidious to make people understand we need the *final* text to start with, I cannot imagine what it would be running around with WP files arriving at the *last minute* (how many are there!!!) for *last changes* (oh! you're telling me!). I think this would be a nightmare. When you have a tight layout, even small editing can affect substantially a page. What do you do then? Change the layout? Edit the Stylesheets? :) I'd rather have a server version of Scribus instead, and all the people who have an interest in the editing part of the work could have access to that particular file. That way, they could see the effects of any change in the actual layout. What if we look at this issue from another perspective? We are very close to automatic file creation. In that case, is there a need to care about editing the oudated file? Users could just recreate a new file in seconds when the text is modified. Data or text (we can think of text as data) could be tagged on the fly with stylesheets and imported into the new document. Provided all decisions were taken accordingly along the editing/production chain. I think we have a feature request on that already. Do I miss something? |
|
|
I'm coming at this from a somewhat different perspective: My production environment is me, myself, and I, so I'm not knowledgeable about issues that arise with larger teams. The biggest part of making a publication for me is generating the text, and Scribus isn't the best application for me to do that. Also, I want to have "source" text that can be published in a variety of formats (e.g., HTML for the web, PDF for downloading and possibly for printing), but for the formats that require it I want the kind of control over the layout that a DTP application provides. I wouldn't be so concerned about text updating if I could guarantee only one iteration of the import text/layout process, but it never works out that way. I find stuff in the text that needs to change, which means I need to change the "source" text document and then update the layout. Or I find a sticking point in the layout and have to restructure the text somehow. Automatic text updating makes that go a lot faster. The text I'm talking about is book-style text with no fancy formatting--for the things that typically require DTP-style formatting adjustments, such as titles, page headers/footers, etc., I do do everything inside the DTP program and automatic text updating from an external document is not an issue. But if I have 30 pages' worth of body text in a publication, I'm not going to do any more formatting to it than will be done on "Get Text" in Scribus; I've already done font selection, paragraphing, line spacing, etc. in the external program. I can't find anything in the database here about "automatic file creation", but it sounds like an interesting feature. Can someone point me to the right issue so I can read it up? |
|
|
I can't find this either. Must have been something discussed on the mailing list. Maybe browsing the archive could be a good idea. I am pretty sure the Team has something to say about data merging/handling with Scribus. Scripting might be something to consider. It just came to mind that one other thing that could partially solve your issue would be the ability to *export* text from Scribus to other formats. Please have a look at bug 0001394 ... it could be a start. |
|
|
moving to 1.3.x |
|
|
Once we have the new 1.3 format in place, I'm hoping it'll be possible to ask a text PageItem to return an XML blob of its contents as they would be saved in the file. This would be of interest to people who hanker for the days of 'show codes' and WordPerfect. It'd also be an interesting way to store Scribus-formatted text outside Scribus. That could be useful for a number of things: - Externally linked text files with full control over formatting - Getting text into and out of CMS systems and databases - Doing funky things with the scripter - An 'edit XML' option for the text frame - ... and no doubt other things I haven't thought of I'm not suggesting that as a replacement for simple linked text, but it might be good for those who want more control and aren't afraid of XSLT, scripting, etc. |
|
|
Reminder sent to: kobuswolf Adding you to the monitor list. |
|
|
On IRC, kobuswolf suggested the approach of using a cut-down Scribus (just the story editor and text load/save support). In a situation where writers use word processors, then you have copy-editors who check, edit, and submit the copy, this sounds like a very good idea to me. It'd probably depend on the new (not yet implemented) Scribus 1.3 file format. The idea would simply be to link to an external file containing the Scribus XML representation of the text (0001394). Scribus, and the copy-editor version, could both edit it (0001925), and pick up changes from each other. Formatting merging problems go away. The file, being simple XML, could be stored in a CMS, versioned, etc too (0001924). |
|
|
Stand alone story editor: http://www.quark.com/products/copydesk/ That way, formatting text with all the typographic possibilities of Scribus would be easy. |
|
|
I think that the formatting should not prevent scribus from having the functionality of automatically re-loading (text-)files because they can simply use the same style-template. Usually it should not be necessary to do that much formatting manually, given that ligatures as well as spaces should be handled automatically and character-/paragraph-styles are put into the imported (text-)file. Currently though, users would have to learn the strings used by the import textfilter and write them into the text. The QuarkCopyDesk can style texts, yet that is not even needed. All one needs is a story-editor that can assign styles to characters/paragraphs. It would open a style-template and the user can assign those styles to the text, as it is currently done in the story-editor. A style-template simply contains the styles created in scribus and their marker for the textfilter. An example: Currently I can open the story-editor and assign styles to paragraphs, e.g. "main-heading". One could then assign a marker to that style, e.g. \H1:. The user's story-editor now shows him the style "main-heading" which he applys to a paragraph, just the name, he does not see any formatting, just that the paragraph will get the style "main-heading". The story-editor saves the paragraph with \H1: in front of it, since that is the marker given in the template for the style "main-heading". All scribus has to do on re-loading that file is replace the \H1: by the style this marker is assigned to. The small spaces are mostly numbers, abbreviations etc. which can be handled/filtered automatically. So there are just a few things remaining, that one would have to format manually, e.g. non-breaking spaces, yet the advantages for collaborative work outweigh the downsides by far. |
|
|
I'd just like to throw my two cents in and say that this is the only feature that is keeping me from using Scribus. The style issue for me wouldn't be a problem as I'd be using OpenOffice or just plain HTML to do all my formatting. Using style-templates wouldn't be too bad, either. However, for someone who has a large document in which many people could be editing different parts of it in different files at the same time, merging them all together into a Scribus document would be multitudes easier if only it could automatically import new changes. Imagine Scribus combined with a version control system and you would have a very powerful tool, especially if one stored different sections of the document in separate HTML files. |
|
|
The lack of this feature also, unfortunately, keeps me on LibreOffice for document development. I use their Sections linking feature to unformatted text and am happy with it, but would love to be able to use Scribus' other features too. Please consider allowing this capability! |
|
|
This is an essential feature for book layout. If I make any changes to the text -- I need to do it in the original text document, because the same text will be used in the ebook. If I already have a layout, I'll lose it if I re-get that text. Otherwise, I have to painstakingly go through and copy and paste all text changes. |
|
|
This was one of the topics that were discussed during LGM 2012. It is agreed that such feature has become a must in modern workflows that are more and more geared towards collaborative work. The solution should allow : a. Interaction between as many people needed into a given project — with or without permissions — and traces of who did what and who accepts what. b. No need for reformatting when pumping the edited version back into Scribus — being clear that Scribus is the master of the layout and thus the program that pumps the data. c. Proper identification of how the layout was affected by the changes (eg. addition or substraction of line(s) and text reflow issues, new page creation (auto text frames and auto page insertion after text is edited), text overflow, etc.) A web platform could accomplish this. Anyone whishing to further describe what the requirements would be and how this could be implemented is welcome to do so! If you have programming skills too, it would be great to have an estimate of the work as well (hours, days, weeks?). |
|
|
Good to know. That will really open up Scribus to be used on larger projects. The only current workaround for this issue (for those googling it) -- is to create a set of styles in your Open Office or Word document that will match the styles wanted in the final Scribus document (heading, body text, etc...). Setup the document using these styles. In scribus: When using "get text" -- select the "overwrite" option (only). Then, create a set of template styles (ex: t-bodytext, t-heading1, etc...) that contain the main styles to be used. Then, if you need to update the text in the original document -- just re-import (get text), and the only thing that needs to change are the styles. Select the imported style (body text, etc...) and use the "based on" option in the styles pallet and select the appropriate template style. It sounds like a bit of a hassle, but seems to be the simplest way to update edits without losing your formatting. |
|
|
There isn`t any possibility for saving all Scribus related formatting in other file format like ODT or DOC. For now there is problem with inline frames, next will be problem with marks, anchors and references. I am not sure that all styles properties can be saved in ODT or DOC styles. If so, how Scribus can save text frames content with whole information? IMHO we have two ways for it. 1. create separate text editor (standalone Story Editor?) for Scribus text content for cooperative working on texts which can read and apply styles from Scribus document and can show/edit special formatting features (inline frames for example) and save it in its own file format (or maybe in XML). 2. in text files save Scribus related formatting features as markups like <@...> like in old Ventura GEN files. For example: "bla ble bli <@inline:'../img/img.jpg',w100,h50,r0> next text bla bla bla". Or for applying styles: "<@pstyle:Header1>Header for chapter". User has to carefully edit such text so any markups will not change without need. And if needed he can insert Scribus markups into text as they are quite good readable. Both ways have pros and cons. Both ways are not perfect. I am afraid there isn`t any perfect solution. If so, maybe we should give both ways for user`s choose. |
|
|
one more thing we discussed at the recent LGM was to find way to do diff (show differences) inside of scribus. if anybody is interested in working on it (programming!) just put a notice in here! |
|
|
Recently there's some mailing list discussion on this, so I update this ticket. - ale stated to be working on a markdown import plugin - JLuc referred to this ticket (0001791) and to ticket 0010651 - I have started a markup wish-list: 0015215 - One solution not mentioned here (besides https://bugs.scribus.net/view.php?id=1791#c9881) could be to create a single command-line tool + shared library which converts markdown to the Scribus XML format which then can be loaded directly into the text frame. Advantage: all the markdown utilities (RST, txt2tags, ...) out there could generate Scribus output. This could be some "advertising" for Scribus. - I suggest to consider somehow to include marks so that a Python script or the Scribus internal TOC mechanism can ask for the position of some references (or use the reference mechanism of Markdown/RST etc in some other way). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-03-18 23:01 | pdonis | New Issue | |
| 2005-03-19 02:04 |
|
Note Added: 0003925 | |
| 2005-03-19 18:55 | pdonis | Note Added: 0003929 | |
| 2005-03-20 04:10 |
|
Note Added: 0003932 | |
| 2005-03-20 20:03 | pdonis | Note Added: 0003938 | |
| 2005-03-21 16:56 | louisdesjardins | Note Added: 0003940 | |
| 2005-03-21 21:39 | pdonis | Note Added: 0003943 | |
| 2005-03-21 21:40 | pdonis | Note Edited: 0003943 | |
| 2005-03-22 12:15 | louisdesjardins | Note Added: 0003947 | |
| 2005-04-07 20:18 |
|
Note Added: 0004123 | |
| 2005-04-07 20:18 |
|
Product Version | 1.2.1 => 1.3.0cvs |
| 2005-04-08 03:01 |
|
Note Added: 0004140 | |
| 2005-04-26 13:27 |
|
Relationship added | related to 0001394 |
| 2005-04-26 13:28 |
|
Status | new => acknowledged |
| 2005-04-27 06:28 |
|
Note Added: 0004431 | |
| 2005-04-27 07:00 |
|
Relationship added | related to 0001924 |
| 2005-04-27 07:06 |
|
Relationship added | related to 0001925 |
| 2005-04-27 08:16 |
|
Note Added: 0004439 | |
| 2005-06-21 02:37 |
|
Relationship added | related to 0002108 |
| 2005-07-14 00:30 |
|
Relationship added | related to 0001132 |
| 2006-04-12 21:59 | mhanski | Relationship added | related to 0000111 |
| 2006-04-12 22:01 | mhanski | OS | SuSE => all |
| 2006-04-12 22:01 | mhanski | OS Version | 9.2 => all |
| 2006-04-12 22:01 | mhanski | Platform | i386 => all |
| 2006-04-12 22:01 | mhanski | Product Version | 1.3.0cvs => 1.3.4cvs |
| 2006-04-12 22:01 | mhanski | Build | 08 January 2005 C-C-T => |
| 2006-04-12 23:23 | louisdesjardins | Note Added: 0009881 | |
| 2006-04-13 11:34 | mhanski | Relationship added | related to 0000011 |
| 2006-04-13 13:18 |
|
Product Version | 1.3.4cvs => 1.3 |
| 2006-05-16 21:50 | christoph_s | Relationship added | related to 0003828 |
| 2006-11-01 09:49 | rabauke | Note Added: 0013217 | |
| 2007-09-17 15:29 | nwidger | Note Added: 0017306 | |
| 2012-04-16 23:04 | kahu | Note Added: 0027941 | |
| 2012-05-07 05:50 | mjj777 | Note Added: 0027985 | |
| 2012-05-07 15:52 | louisdesjardins | Note Added: 0027986 | |
| 2012-05-08 01:38 | mjj777 | Note Added: 0027987 | |
| 2012-05-08 06:32 | cezaryece | Note Added: 0027988 | |
| 2012-05-08 11:10 | ale | Note Added: 0027990 | |
| 2012-10-16 08:38 | ale | Relationship added | related to 0010651 |
| 2015-09-17 20:08 | Kunda | Category | Story Editor / Text Frames => Story Ed/Txt Frames |
| 2015-09-17 20:12 | Kunda | Category | Story Ed/Txt Frames => Story Editor / Text Frames |
| 2016-05-06 19:40 | JLuc | Relationship deleted | related to 0003828 |
| 2016-05-06 19:41 | JLuc | Relationship deleted | related to 0000011 |
| 2016-05-06 19:42 | JLuc | Relationship deleted | related to 0001924 |
| 2018-03-24 08:27 | u ltd. | Note Added: 0045085 |
