View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000245||Scribus||Story Editor / Text Frames||public||2004-02-03 17:23||2016-04-12 14:56|
|Summary||0000245: Automatic addition of new pages with auto-text frames.|
|Description||When a new document with automatic text frames is created make Scribus use the font size and face of the first page's text fram and add the necessary number of new pages to accomodate an import of a large amount of text.|
|Additional Information||Discussed this with Craig Bradney. He suggested filing a bug report/feature request.|
|related to||0001410||acknowledged||Allow automatic text frames after document has been started|
|related to||0001592||confirmed||New textframes not linkable to "Autoframes"|
|has duplicate||0001790||closed||No autoflow of text to new frames/pages|
|has duplicate||0003444||closed||Automatic creation of new pages/frames while filling text|
|has duplicate||0001342||closed||auto adding of pages|
|has duplicate||0008407||closed||jghali||auto creation of pages|
|related to||0001098||acknowledged||Feature request ot manually integrate Shift+Click automatic text frames (without using mouse)|
|related to||0003837||acknowledged||Metabug: Master pages/Page templates|
|related to||0002673||feedback||Linking and unlinking of automatically created text frames doesn't work correctly|
|I've just written a script to do this, and scripting is a viable if clumsy alternative. See bug 1036.|
|This can probably be done properly once the PageItem cleanup work is finished and text reflow has moved out of PageItem::DrawObj .|
The only thing I can say is this would be a *most* welcome addition.
So, *all my encouragements* to the programmers!
We need that for production, although there is a not-so-clumsy workaround which made it quite a few times in the mailing list. :)
It will only make things easier, more intuitive, more of what I'd call an expected behaviour.
As it is right now, it's like having an extra bus stop, just before the terminus. An extra bus stop but where nobody ever gets on the bus or gets out of it! :)
(Sorry for the little redundance, but I was answering to this when the bug was turned off... Couldn't post my note! Still think the explanation is worth it for some readers and for the reporter of the bug 0001790 and also I have an addtionnal note at the end. Again, sorry for that many words.)
What is not yet implemented is something we could call "Auto Page Insertion".
What works is the following:
1. Set margins and check the "Automatic text frame" option when in the "New" dialog. Click OK.
2. Import text in the text frame. If text is too long for that frame, it will be just as pdonis describes in 0001790 no extra page created, a red x in a square at bottom right of the frame.
3. Go to the Page menu and add some more pages. These newly created pages will have a linked text frame to the first page and your text will flow into them.
There currently is no need to:
a) draw a frame in each page and
b) manually link it to the previous page.
The missing feature really is an "Auto Page Creation" (or Insertion). And we need that as a separate feature because as there are moments when you want pages to be automatically created, there also are moments when you really don't need that!
||I'd like to add one other missing feature to the list here. The workaround louisdesjardins describes is fine as long as you just have one text story in the document. But what if there's more than one? For example, what if you have "sidebar" stories which are not part of the main one? By default, every text frame you add to the document is linked to the previous ones (holding the main story), but if you start manually unlinking them, Scribus seems to become confused fairly quickly about what should be linked to what, and the link and unlink buttons no longer seem to work as expected. If one or more of the "sidebar" stories also needs to flow from page to page, that seems to get even gnarlier. It seems to me that the level at which "automatic text frames" really needs to function is the story level, not the document level--i.e., when new frames are added using automatic text frames, the user needs to be able to specify the story to which they should be added.|
I read your post with much interest.
If you'd like to take a look at the related issue 0001410 ... I think we can work out a nice suggestion for the devels about this feature to come.
I read the note in the other issue, but I'm not sure that doing "auto text flow" at the section level is good enough. I still think it needs to be at the *story* level (where a "story" consists of one or more text frames linked together, and appearing on one or more pages, each of which may also have other text frames containing other stories, or other stuff besides text). A section of a document might still contain multiple stories, and I think you'd want to have separate control of auto text flow for each one.
As a comparison, in Adobe PageMaker, when you have "autoflow" checked (it's a menu option, can't remember exactly which menu), and you place an external text document, it automatically starts generating text frames, using whatever empty space exists on the page you placed the text and any subsequent pages in the publication; if it gets to the end of the publication and there's still text left to place, it automatically adds pages and creates new text frames on them and auto flows the text into them until it's all placed. None of this affects any other text frames in the publication, which may also be linked among multiple pages (or columns, if you have multiple columns per page). This is the kind of thing I'd like to be able to do in Scribus. I should emphasize that once you've done what I've just described, there is still cleanup to do with the layout--auto text placement won't get everything exactly right. But I'm not looking for something that will get it exactly right; I'm just looking for something that's easier to clean up after than what's there now.
I would suggest the "automatic text frame" option be removed from the "New" dialog and be put instead at "Template" level where each text frame created there could be given the choice to be:
[ ] Automatically linked to next page based on that template
[ ] Automatic page insertion when text doesn't fit
[ ] No automatic linking (so, pages are created with frame but these frame are not linked together)
[ ] Editing not allowed outside the Template dialog (as it is right now)
This needs more "engineering thinking" but you get the basic idea.
I think that way we get full control over what flows where and changes can be made at any time during the work. Also, you can have as many frames as you wish that automatically link to another page, which is not that case at the moment. And you are still allowed to manually link any text frame along the way.
We could even think of a layout where there are 2 or more text frames linked together on the same page and this pattern repeats on every page (could even be mirrored on facing pages). This could be done by manually linking the frames on the templates and specifying to the last one that it must link to new pages based on the same template.
We need a way of telling Scribus to start a new linked chain or not from the Page>Insert page dialog.
If I recall well, this is how it looks in XPress (check box):
[ ] Link to current chain.
This is helpful when you want to add a whole new section to a document and need the auto frame so all new pages can be automatically linked together w/o affecting the previous chain.
the description out of the dup 3444:
This feature exists reportedly both in InDesign and Quark and works this way:
1. pressing SHIFT while filling text into a text frame causes the program to automatically generate new pages and chained frames, needed for the whole text
2. if the text grows to long for the existing chained frames, the last frame in chain will display a text overflowing icon => SHIFT+click on the next page results in automatic creation of new pages/frames as in 1.
I suggest a "first frame" and "last frame" property for this.
On a page, text will start at the "first frame", will follow the flow until "last frame", then if space is still needed, "last frame" will automatically be linked to the "first frame" on the next page.
I guess texts/?content? could benefit having a name in this case. For example, the main body of text could be named as "body_text" by the user.
First frame and last frame could use this. For example in the properties, user could have:
-Type of frame: Normal/First/Last
-Use content: body_text (from a drop-down list)
This would have the effect of flowing the correct text and making .
Adding this then requires the addition of a "text library" of some kind, for easy storage of texts. Only tagged texts would be placed there, so minor texts or titles (unless stated) won't clutter the list.
Also what would be useful or interesting would be a child-parent relationship (especially for long books). That would allow for example to have texts separated as chapters, and while being editable as separate parts, flowing them with the name of their parent would be more efficient than creating multiple text/content names.
For example a bunch of paragraphs dissociated:
-Paragraph 5, part 1
-paragraph 5, part 2
Now with the parenting:
+--Paragraph 5, part 1
+--paragraph 5, part 2
Also for untagged text, I suggest that flowing have automation on new page creation. There could be a "Flow last to first" checkbox that would flow the text currently selected on the page.
I like PLucAuclair's suggestion for first and last frames, as well as the tagged text library for organizing multiple stories and related parent/child blocks of content addressable as a group. I think this would fall within the scope of my suggestion for compound object styles in 0003578 (see linked text flow point near the end).
What I was suggesting could be used both at a per-page level as discussed here if used as a master page (including for facing or multipage spreads as louisdesjardins mentioned) and for custom linked groups of frames within pages which could be placed manually or embedded in multiple different master page definitions. Maybe this would make a nice general framework in which to implement this? :)
|2004-02-03 17:23||malex||New Issue|
||Note Added: 0002312|
||Note Added: 0003852|
|2005-03-02 12:49||louisdesjardins||Note Added: 0003853|
||Relationship added||has duplicate 0001790|
||Relationship added||related to 0001410|
|2005-03-19 02:33||louisdesjardins||Note Added: 0003927|
|2005-03-19 19:35||pdonis||Note Added: 0003930|
|2005-03-20 01:03||louisdesjardins||Note Added: 0003931|
|2005-03-20 19:38||cbradney||Relationship added||related to 0001592|
|2005-03-20 20:00||pdonis||Note Added: 0003937|
|2005-03-21 17:14||louisdesjardins||Note Added: 0003941|
||Status||new => acknowledged|
|2006-03-02 15:33||louisdesjardins||Note Added: 0009004|
|2006-03-16 08:51||jo-hannes||Note Added: 0009327|
|2006-03-16 08:51||jo-hannes||Relationship added||has duplicate 0003444|
|2006-04-08 15:15||PLucAuclair||Note Added: 0009695|
|2006-04-08 15:40||PLucAuclair||Note Edited: 0009695|
|2006-04-08 21:53||mkoren||Note Added: 0009725|
|2006-04-12 12:28||mhanski||Relationship added||has duplicate 0001342|
|2006-04-14 22:02||mhanski||Relationship added||related to 0001098|
|2006-05-18 18:28||christoph_s||Relationship added||related to 0003837|
|2009-11-05 22:24||jghali||Relationship added||has duplicate 0008407|
|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|
|2015-11-24 00:33||Kunda||Relationship added||related to 0002673|
|2016-04-12 14:56||Kunda||Tag Attached: autoframes|