View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003266 | Scribus | Story Editor / Text Frames | public | 2006-02-18 23:26 | 2016-01-19 12:36 |
| Reporter | christoph_s | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | 1.3 | ||||
| Summary | 0003266: Enable changing the number of columns in automatic text frames | ||||
| Description | Currently, 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. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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. |
|
|
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. |
|
|
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! |
|
|
I guess that will be irrelevant when #columns becomes a paragraph option. |
|
|
Ah, is this planned? I still think columns would be better placed in a frame style. |
|
|
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? |
|
|
But Scribus is a frame based layout app. The typical and effective solution is to create a separate frame for the headline. |
|
|
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. |
|
|
>>>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. |
|
|
My 2c, IMO, columns are a frame attribute... (perhaps also frame style once we have such a thing) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
>>>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. |
|
|
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. |
|
|
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". |
|
|
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. |
| 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 |
