Feature discussion: column flow

[BN_Dev]

Hi all,

^^ With regards to this post ^^

An essential feature we need is something analogous to column flow in QuarkXPress.  See QuarkXPress 2024 User Guide: Controlling column flow.

This has already been discussed a little on the Mantis issue tracker by somebody else wanting this feature; see 0016049: Span Columns for selected text.

I won't rehash everything already said there as it's probably best to read that for the details.  But the essential real-world use case is for a newsprint production being able to flow even just the first paragraph over multiple columns would save a huge amount of time when laying out stories with the headline (and maybe the subheading) being in the first (plus maybe second) paragraph.

The time saved would be measured in hours per day and would drastically simplify updating layouts when you only have to move a single text frame per story and don't have to deal with grouping/linking/welding/moving/etc. multiple text frames.

Although the column flow could support all sorts of weird and whimsical combinations, 99% of the use case for most people seems to be just for headlines on the first paragraph and this would be the only thing needed to make the Scribus workflow as efficient as the QuarkXPress workflow when doing the layout.

Many thanks,
Paul

[a.l.e]

personally, i fear that people will start doing the full layout inside of text frames:
if somebody is coming from the word processors world, this is probably the most logical way to do it.

and then they start being frustrated, because it gets harder and harder when they start adding images and legends for them.
and then the culprit is scribus and its developers.
(we have already seen such complaints many time in the past, even with the current very basic columns for frames)

on the other side, i understand why, for power users it can be a game changer in specific cases!


the big question is: how to extend this feature so that it will "only" be used in the cases where it's really useful?

[Nermander]

Could't the desired effect essentially be managed by linked frames?

Multi-column body text frame in the bottom, on top of this the heading frame spanning two columns.

Link the heading frame to the body text frame.

Now, the big issue of course is if the headings have such a variable size that the height of the heading frame would need to be dynamic. But maybe dynamic frame height could solve this (there are already scripts to adjust the frame height I think, but I am not sure how they would work with linked frames since I guess they depend on overflow).

[a.l.e]

In my eyes, this is a very typical layout that is "hard" to achieve with the in-frame columns:



People who have only learned about columns inside of frames, will really struggle to achieve it.

With a better typographical grid and a powerful welding system (moving down the title's bottom border would move down the columns, the image and the legend...), in many (if not most) cases, it would be "easy" to put such a "structure" in the scrapbook, then pull it out from there when it's needed, and adapt it to the specific page.
It would be more complex to setup, (hopefully) just a bit harder to use, but way more flexible and fast for the cases that are just slightly different.
(and the beginners only need the typographical grid, not the welding!)

But can we really hope that Scribus will get there in a foreseeable future?

On the other side, it's clear that with the way Scribus currently works and for the layout Paul is supporting, having slightly better columns inside of the frame looks like the most straightforward solution.

[utnik]

i would still prefer the 'column span' as a part of the definition of the paragraph style.
welding may be a solution. but you need to import the 'overspanning' paragraph as a separate text...

utnik

[a.l.e]

ps.: no, in my example above there is only one text flowing through all the frames (title + columns; of course not the image legend)

pps.: if the column / frame break would work correctly, it would even be more comfortable to jump to the first column after the title.

ppps.: as i wrote, i don't think that the current implementation of welding cannot move and resize all the relevant frames at once, when resizing the title part... and it can for sure not do it in a reliable and comfortable way.

[BN_Dev]

Regarding potential solutions and discussions on this; please also consider the primary motivation for this feature being added in QXP/ID is to increase speed of layout. Pasting a story in to a text frame and applying the headline style to the first paragraph is 90% of the job done for a newspaper layout...
Press t (for text tool), 1 drag (create text frame), press Ctrl+V (paste), 1 click (in first para), 1 click (on style pallet). 3 keys and 3 mouse clicks 
How many interactions are required to achieve the same with multiple frames, creating welds, groups, etc. etc.

[a.l.e]

- pull the prepared layout with welds from the scrapbook
- press i + click on the title frame
- paste
- apply the title styles
- adjust the height of the top frame

(specific welds are created in advance for multiple use cases)

this is:

- 2 click and drag
- 2 keys
- 3 mouse click

please don't get me wrong: for your specific use case (a very strict layout with text only), i'm sure that having multiple columns per frame is the fastest and simplest solution.
and i also believe that the solution you're suggesting is the fastest to implement.

the issue i want to raise is: way too many people, when they see a hammer they use it for everything.

my goal here is "just" to highlight the dangers hidden behind this feature and get it implemented in a way that it does help the people to use it in the right way.

(well, my goal might also be to show that having a good welding system would also help make scribus a better fit for workflows that need to be fast and flexible)

[BN_Dev]

Apologies for delay in replying to this, I was firefighting some QXP issues and had some vacation time.

I'm not against welding but when I had a play with this I couldn't easily wrangle it behave how I needed; but that might be lack of understanding on my part.

One of the "pros" for implementing column flow as part of the existing text frame is it could be set as a style property, so in the story editor it would be incredibly easy to style (or import a pre-styled story) and your plain text frame suddenly looks a lot like a publishable article.

I personally think the way QXP and ID implemented column flow is just wrong - it's far too liberal and allows bizarre levels of complexity and user stupidity/danger. Most of which normal professional users wouldn't/shouldn't ever need.

I think if Scribus had this feature it should be as simple as possible (just to allow a headline) which would solve for 90%+ of use cases in newspapers and magazines. Anything above that should be done with multiple frames. By deliberately retarding the functionality we could nudge the user in to using the right tool for the job.

I want to play more with frames and welding because my initial learning didn't seem to go so well and I want to make sure I didn't miss anything.  In your suggestion, am I understanding right that I need to pre-create a scrap book of welding styles?