View Issue Details

IDProjectCategoryView StatusLast Update
0003266ScribusStory Editor / Text Framespublic2016-01-19 12:36
Reporterchristoph_s Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status feedbackResolutionopen 
PlatformallOSallOS Versionall
Product Version1.3 
Target VersionFixed in Version 
Summary0003266: Enable changing the number of columns in automatic text frames
DescriptionCurrently, the number of columns in automatic tet frames is fixed with the creation of a new doc. It would be useful to change the number of and the distance between automatic text frames after creating the new doc in document setup > document.
TagsNo tags attached.
Patch

Relationships

related to 0003735 closedavox Number of columns as a paragraph option. 
related to 0001098 acknowledged Feature request ot manually integrate Shift+Click automatic text frames (without using mouse) 

Activities

louisdesjardins

2006-02-19 23:16

developer   ~0008815

I tend to agree but I'd like to know whether the change would affect only the newly created pages? In my view, this feature would be useful if it was so. Otherwise, it will be difficult to handle, imo.

christoph_s

2006-02-19 23:37

administrator   ~0008818

It can be difficult to handle sometimes, but I think the choice should be left to the user: a) apply to all automtically created frames b) aplly only to new pages.

louisdesjardins

2006-02-20 01:33

developer   ~0008822

Yes. Better. I was wrong thinking this as a one way feature. With this choice for the user, I think, as you, it would be useful.

Agree!

avox

2006-04-29 21:11

administrator   ~0010648

I guess that will be irrelevant when #columns becomes a paragraph option.

christoph_s

2006-04-29 21:28

administrator   ~0010654

Ah, is this planned? I still think columns would be better placed in a frame style.

avox

2006-04-29 21:55

administrator   ~0010659

I thought it would be nice for headings which span several columns.

OTOH I see that it would cause problems if you want a 2-column frame
which is linked to a 3-column frame...

Dunno. Opinions?

christoph_s

2006-04-29 21:58

administrator   ~0010660

But Scribus is a frame based layout app. The typical and effective solution is to create a separate frame for the headline.

louisdesjardins

2006-04-29 22:53

developer   ~0010666

I can't think of where we'll be heading with column control at frame AND paragraph level...

My first thought on this is it would be complicated to handle. I think the two ways are mutually exclusive.

At the same time, I understand that sometimes having 2 text frames just because youi have a headline over a two-column story is clumsy... It breaks the text... But again, just how well this column option is going to work... how will it equilibrates the columns... how will it handle widows and orphans...

But I am ready to discuss this thoroughly. I am not sure at all this is a bad idea although I do have some concerns.

But I can think of many situations where this approach would simplify the life of the user, depending again on how well the feature is developped.

christoph_s

2006-04-29 23:17

administrator   ~0010668

>>>My first thought on this is it would be complicated to handle. I think the two ways are mutually exclusive.

Yes, exactly my thoughts. This would probably mean begging for confusion and screwing things up.

>>>At the same time, I understand that sometimes having 2 text frames just because youi have a headline over a two-column story is clumsy... It breaks the text...

But a headline within a text frame will break the text too. And a headline in separate frame above the text will indirectly break text too since the break ocurs at the end of the text frame anyway.

>>>But again, just how well this column option is going to work... how will it equilibrates the columns... how will it handle widows and orphans...

And what about distances above and below, control of line spacing, baseline grid etc. ... Implementing this on a per paragraph base would make things unnecessarily complicated for users. Why not keep it simple, stupid?

>>>But I am ready to discuss this thoroughly. I am not sure at all this is a bad idea although I do have some concerns.

>>>But I can think of many situations where this approach would simplify the life of the user, depending again on how well the feature is developped.

IMHO, the costs in terms of development time and configuration time for users don't justify the approach. Also, a frame based approach offers a maximum of flexibility and control. Once a user has understood the principle, it's almost "natural" to go down this road.

cbradney

2006-04-30 08:53

administrator   ~0010675

My 2c, IMO, columns are a frame attribute... (perhaps also frame style once we have such a thing)

louisdesjardins

2006-04-30 11:25

developer   ~0010697

Yes. I don't disagree with Christoph and Craig. Frame based apps allow to handle 100% of the cases... for years now.

The field where I think this idea might be of interest is in database automatic formatting and layout. But again, with proper use of Master Pages + the addition of column change asked by Christoph might solve the case.

PLucAuclair

2006-04-30 16:28

reporter   ~0010703

Last edited: 2006-04-30 16:32

I don't agree with you Craig, IMO columns should not be *only* a frame attribute. I think we could very well have both coexisting.

What I find interesting with columns as a paragraph style is that you could do something like:

MMMMMM

MMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMM
MMMMMMMMMMMMMMMMM

MMMMMMMM MMMMMMMM
MMMMMMMM MMMMMMMM
MMMMMMMM MMMMMMMM
MMMMMMMM MMMMMMMM
MMMMMMMM MMMMMMMM
MMMMMMMM MMMMMMMM

within a single frame instead of breaking your text frame. I can see it being useful for different types of formatting.

christoph_s

2006-04-30 17:52

administrator   ~0010704

Last edited: 2006-04-30 17:54

PLucAuclair, I still can't the advantage of your approach compared to text frames. But I see disadvantages. Let's assume columns were paragraph based and you would like to have an article in one frame. You let the continuous text snap to baselines, the headline probably not. Then you have the space above and below paragraphs, which will interfere. How do you place your headline reliably and with precision? That's the typical clumsy word processor approach which wastes a lot of time. If you keep things separate, you can work faster and you have more control.

louisdesjardins

2006-04-30 18:03

developer   ~0010705

Would you agree splitting this bug report in two? The discussion on columns as a frame or (and) a paragraph attribute is interesting but has not much to do with what Christoph is asking for on the first place and which I think is a good idea!

I understand avox thinks this is somewhat irrelevant but at the same time, we have to acknowledge Scribus works with frames and this is the only way we have for the moment to deal with columns.

We could relate the two feature requests for further reference but they are of a different taste anyway, imo.

PLucAuclair

2006-04-30 18:51

reporter   ~0010707

christoph_s, it's not about replacing it, it's just adding another one. What I'd rather see are some texts breaking the two column layout on some places. It's not totally more powerful, it's another way of doing.

I don't agree with the baseline argument though, you can very well have everything not break the baseline even with such a feature.

mkoren

2006-05-02 00:36

reporter   ~0010760

>>>Frame based apps allow to handle 100% of the cases... for years now.
>>> ...a frame based approach offers a maximum of flexibility and control.

This is true of course, that's why we use a layout app--there's always a way to achieve the desired layout eventually, but the question is how easy is it to set up and maintain? What if you need a consistent look for your headlines across multiple documents? I can see advantages and disadvantages to both approaches.

>>> How do you place your headline reliably and with precision? That's the typical clumsy word processor approach which wastes a lot of time. If you keep things separate, you can work faster and you have more control.

Again, I would agree for many individual situations where total control is needed. But when interdocument consistency is required, or if you just come up with an approach you like and want to reuse, a _much_ more important time consideration in the long run is the ability to use styles to recreate a layout, no matter how it was initially created.

At the moment, the only way this would be possible is if a column-aware paragraph style could be created with carefully thought-out "line spacing, baseline grid," "space above and below paragraphs," etc.

But Christoph, this is exactly why I have proposed to have layout and object styles that allow relative frame placement, as in 0003578 and 0003672, which you said would be too complicated. But this would let you place your headline with full precision as a separate frame, select it and the main text box, and save the relative configuration as a compound object. Can anyone think of a simpler way to achieve this functionality?

I personally would much rather spend more time up front creating good styles than have to recreate common formatting for every document.

louisdesjardins

2006-05-02 03:03

developer   ~0010763

Last edited: 2006-05-02 07:48

Again, this is a complete different discussion. We will not be able to find easily this when we get to 6000 bug reports... :) If we could only split the report in two different issues... Just asking.

I actually don't see how we cannot achieve consistent looking documents with the actual approach. In my office, we layout every year *hundreds* of pages for different magazines and other publications, each of them having to be graphically and typographically consistent. We are using Quark which basically has a similar approach, frames and stylesheet. It's very fast, and very efficient.

I am ready to discuss other approaches and it can lead to interesting new ways, but can we be more specific on just what really are the benefits? And it doesn't hurt to mention what software we refer to or what was done and how... and why we need this new approach.

<quote>Again, I would agree for many individual situations where total control is needed. But when interdocument consistency is required, or if you just come up with an approach you like and want to reuse, a _much_ more important time consideration in the long run is the ability to use styles to recreate a layout, no matter how it was initially created.</quote>

But that is absolutely possible at the moment. Not only can you reuse stylesheet in one document but also from one document to another (append stylesheet), and through scrapbook, master pages, templates, and duplicating pages from the page menu, and line styles. I mean, at this point, what is it that cannot be done with total control (total) and consistency, from one document to another?

From the actual discussion so far, what I understand sounds to me like either a document approach that is more text oriented than anything else (like tex) or web publication. Scribus has certainly web capabilities from the PDF stand point. But it is a print oriented DTP app. Now, I don't want to prove anybody wrong. I just want to understand and this is where I stand right now.

So basically, can you be more specific when saying "you just come up with an approach you like and want to reuse"... Again, I need to understand to sort this out. Currently, I am not sure I get to see the whole picture.

pingu

2006-05-02 07:36

reporter   ~0010765

May I add my experience from VenturaPublisher? It has an option to keep a
paragraph "column-wide" (standard) or "margin-wide". It didn't work very well - except for headlines where it was just great! Impossible though to use it in the middle of a multi-column. I don't think you should try to achieve that, it'll end up in a mess. (Both for programmers and users!)
But how about not setting #columns in paragraph, but having an option to let a paragraph cross the entire frame? Of course users need to understand where this can be used and where not, but that's pretty easy: "intended for headlines only".

mhanski

2006-05-02 08:06

developer   ~0010768

I've moved the "#columns as a paragraph option" topic into the new RFE 0003735, as requested by Louis.

Please let's focus back on christoph_s' request.

Issue History

Date Modified Username Field Change
2006-02-18 23:26 christoph_s New Issue
2006-02-19 23:16 louisdesjardins Note Added: 0008815
2006-02-19 23:37 christoph_s Note Added: 0008818
2006-02-20 01:33 louisdesjardins Note Added: 0008822
2006-04-17 14:07 mhanski Product Version 1.3.3cvs => 1.3
2006-04-29 21:08 mhanski Status new => feedback
2006-04-29 21:11 avox Note Added: 0010648
2006-04-29 21:28 christoph_s Note Added: 0010654
2006-04-29 21:55 avox Note Added: 0010659
2006-04-29 21:58 christoph_s Note Added: 0010660
2006-04-29 22:53 louisdesjardins Note Added: 0010666
2006-04-29 23:17 christoph_s Note Added: 0010668
2006-04-30 08:53 cbradney Note Added: 0010675
2006-04-30 11:25 louisdesjardins Note Added: 0010697
2006-04-30 16:28 PLucAuclair Note Added: 0010703
2006-04-30 16:32 PLucAuclair Note Edited: 0010703
2006-04-30 17:52 christoph_s Note Added: 0010704
2006-04-30 17:54 christoph_s Note Edited: 0010704
2006-04-30 18:03 louisdesjardins Note Added: 0010705
2006-04-30 18:51 PLucAuclair Note Added: 0010707
2006-05-02 00:36 mkoren Note Added: 0010760
2006-05-02 03:03 louisdesjardins Note Added: 0010763
2006-05-02 07:36 pingu Note Added: 0010765
2006-05-02 07:48 louisdesjardins Note Edited: 0010763
2006-05-02 07:54 mhanski Relationship added related to 0003735
2006-05-02 08:06 mhanski Note Added: 0010768
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-01-19 12:36 Kunda Relationship added related to 0001098