View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003735 | Scribus | Styles | public | 2006-05-02 07:53 | 2006-12-23 23:28 |
| Reporter | mhanski | Assigned To | avox | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Platform | any | OS | any | OS Version | any |
| Product Version | 1.3 | ||||
| Summary | 0003735: Number of columns as a paragraph option. | ||||
| Description | quoting avox from bug 0003266: 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? | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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. |
|
|
mhanski, you can't just copy the other notes over for us, can you? I want to reply to Louis's last comment in 0003266 but I don't want everything to end up out of order here if I do it now. |
|
|
Just copy and paste the text mkoren. |
|
|
[Here. I copied my own last note from 0003266. I guess some round trips to that report will be necessary to read all the previous comments. Hope this is going to be clear anyways!] 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. |
|
|
(Copy from 0003266) 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 must add - I simply must...! What if: You add the break-control we've discussed, and leave the rest to the user? Like this: Paragraph C1: Break before; Right indent 100 Paragraph C2: Break none; Left indent 50; Right indent 50 Paragraph C1: Break after; Left indent 100 See? You now have created 3 columns, problem is solved! Please believe me, break-control is so very useful! And without the need for extra programming - only one feature added, then you just sit back and rejoice! Now I know this isn't always easy to use, I'll be more than happy to write a user-guide "Tips and tricks with paragraph breaks". (For headlines, that "frame-wide" option is a better choice. And you're working on character-styles; man, we're getting a terrific DTP-app, unlike any other in the world!) Yes, Scribus is frame-based, it has to be. Let's just get one step closer to "keep together what belongs together". |
|
|
[Yuck, this is confusing. Here is my last note from 3266 that Louis was responding to.] >>>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. |
|
|
Responding to Louis: >>> 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) ... Exactly, styles are extremely useful, I'm saying more elements of the layout should be stylable. You can't currently use a style to specify the position of a headline over multicolumn text. >>> ... 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? But duplication and templates are not as flexible as styles. Sure, you can create 100 documents/pages/etc. with exactly the same layout, but I want to take my carefully designed 18pt, bold, tracking-adjusted heading frame (or whatever)and place it exactly 15.75pt above the following text frame, with the widths matched automatically...no matter what the size, position, or number of columns of the following text is. Or maybe I want the font size and distance from main text to be proportional to the size of the follwing text, and automatically use the same font and color.... This is a styles issue. And by the way I haven't seen this in any other apps, I just think it's about time.... :) >>> 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. I presume you're talking about identical overall layout, right? But how easy is it to add a new sidebar or something on a page for one issue? Don't you have to create the sidebar layout from scratch, then resize the main text _and_ its headline frame, making sure that all the new frames remain consistent in appearance with the whole? >>> what I understand sounds to me like either a document approach that is more text oriented than anything else (like tex) or web publication. I'm not that familiar with CSS but I think it may have some useful concepts here applicable to printed layout as well. |
|
|
mkoren, pingu, I can't answer all of your points right now (late at night, too many). As a general comment, I learned that both of you have different backgrounds both of which aren't exactly working with frame based apps. This is important, because one has to learn to "think" frame based. The use of guides, templates, scrapbooks etc. fits every need, whereas text based thinking requires a lot of configuring on the user side. Believe me, once you have understood the power of this way (esp. in terms of flexibility), you won't need "workarounds" like break control etc. In real world production, it's not so important to have a defined distance between headline and article or a ratio depending on font size. It's more important to adjust items and letters a few points here, a few picas there, until the overall layout fits. That's hard work sometimes, and automagic will hardly help you -- quite the contrary. It depends on your eye, your knowledge and your taste. But in general, with a bit of experience you can work both extremely fast and flexible. |
|
|
>>> you have different backgrounds both of which aren't exactly working with frame based apps.<<< Wrong. Ventura is frame-based, OpenOffice is not. A DTP-app has to be frame-based, there's no arguing against that. But that doesn't mean that a new frame always is the best solution! >>> ... one has to learn to "think" frame based. The use of guides, templates, scrapbooks etc. fits every need.<<< I can't really believe you put every paragraph in it's own frame, do you? Think about it: Scribus has paragraph styles - why? Of course we use frames, but manipulating text is best done with text-manipulation tools. I have given several examples, now one more to answer to: >>> once you have understood the power of this way (esp. in terms of flexibility), you won't need "workarounds" like break control etc. In real world production, it's not so important to have a defined distance between headline and article or a ratio depending on font size. It's more important to adjust items and letters a few points here, a few picas there, until the overall layout fits.<<< On one page I have our teams football-matches this year, looking like this: Spring Autumn Teamname team A date & time date & time date & time date & time Teamname team B date & time date & time date & time date & time I could work only using frames (like I do today, that page took ages!): "Spring Autumn" in one frame, Teamnames in one each, each teams date's in one each. That means creating 19 frames that needs to be tied together! Or I could put all teams dates in one 2-columnframe, leaving an empty line for headline "Teamname", then position the frame containing the Teamname. That is not to "work both extremely fast and flexible". Instead I create a one-column frame and three paragraph styles; One for headlines, one for leftside-dates and one for rightside-dates. That's all it takes! Now think of all three solutions: having finished the page you're told there are three more dates to be added. How do you create the extra space needed? By ungrouping all frames, then adjusting each one of them in size & position - if you need to change the first frame you will have to adjust every frame! - or by changing pointsize or distance in two paragraph styles? Which way do you think is fast and flexible? |
|
|
In the given example, the same result could be achieved using paragraph styles. Just set up the tabs in the stylesheet and you'll be done in seconds. It is very unlikely to use 20 text frames to set up such a table. The one thing we do need and we don't have yet is the character style. If you need more room, edit the stylesheet and tighten the linespace as you suggest anyway. Another way is using the table frame. You mentionned that we need more stylable elements and I totally agree with this approach. It has been discussed and IIRC accepted as a general enrichement of Scribus. We already have Line Styles which Quark doesn't have (for one). Very useful. IIRC from discussion on the ML, text frame styles (or frame styles) are on the radar too. |
|
|
In addition to louisdesjardins: What would be needed in the case of pingu, are configurable tabs. For this, we need character styles that can be applied to single tabs. But this has nothing to do with text coloumns, rather with (imaginary) table columns, created by tabs. That way, pingu's problem would be solved easily. And, pingu, what you described cannot be achieved by paragraph based columns as discussed here. The columns we are talking about are columns for continuous text. |
|
|
>>>Just set up the tabs in the stylesheet and you'll be done in seconds.<<< Yes - if the text was written that way... (First date spring, first date autumn, second date spring, second date autumn etc.) It wasn't. And the people writing should not need to bother about the layout! Christoph, I do like the idea with character styles. It sounds like a very good solution to a bunch of problems. I just think break control would be a very nice addition! And as to the question here (# of columns as paragraph option), it could serve as a good enough solution. The normal way to use columns is to define them in the frame, no arguing against that. Only in some special occasions you need to temporarily change # of columns. (I'm also a bit qurious: As soon as I talk about about breaks you say "No, we work with frames". But character-styles is ok?) |
|
|
>>>Just set up the tabs in the stylesheet and you'll be done in seconds.<<< >>Yes - if the text was written that way... (First date spring, first date autumn, second date spring, second date autumn etc.) It wasn't. And the people writing should not need to bother about the layout!<< pingu, maybe it would be a good idea to provide an example so we can understand. Make a drawing, keep it simple, show us how you would get this text and how it work then. <parenthesis>Also, but this is more of a subjective discussion, I disagree when you say the "people writing should not bother about the layout" because as I understand it is they shouldn't care about what's next and this is not a good way to work. The people writing are part of the entire workflow and if they only cared that bit about what will be going on afterwards, we'd be all more happy. That said, of course, if the tools we have in hand are robust enough to cope with any kind of situation including the examples you are giving, it's ok. But a good communication between all the actors working on a publication seems to me fundamental.</parenthesis> >>Christoph, I do like the idea with character styles. It sounds like a very good solution to a bunch of problems. I just think break control would be a very nice addition! And as to the question here (# of columns as paragraph option), it could serve as a good enough solution. The normal way to use columns is to define them in the frame, no arguing against that. Only in some special occasions you need to temporarily change # of columns.<< 1. Character styles is bug 0000002 in this bug tracker! 2. On my part, as I said in my very first post, I don't disagree with columns being a part of a paragraph style (of course *along* with the current frame method). But I do have concerns, because such a feature has its load of disavantages as well. We have to sort this out. So far, I cannot say I am convinced by the example you have provided. When I say that something can be done easily with the actual tools, my question is: how a new feature could help us do it even faster. But it may only be that, a matter of explaining better. We do our very best to get the whole picture. Obviously, we didn't get to see what you have in mind. Let's pursue and show us examples. >>(I'm also a bit qurious: As soon as I talk about about breaks you say "No, we work with frames". But character-styles is ok?)<< I know all this is closely related at some point but frames and character styles are somewhat a different animal! :) One note about the example that would allow us to understand. It is important that we see the structure, and not only the result on a page. So a drawing would be fine. And screen shots. We are discussing about the way to achieve something. So we should see the steps! |
|
|
OK, I'll try to make it all clearer. It'll probably take a few days, and I think the discussion about break-control is better kept in my original http://bugs.scribus.net/view.php?id=3760 so there's where I will continue to argue! This one is about setting # of columns - break-control allows that to some extent, but not completely. |
|
|
Hi, after this discussion I'll stick with columns as a frame attribute for now. I came up with another feature which might help: a "flush columns break" control which would balance all existing columns and then start again below that. E.g: text1 text4 text7 text2 text5 text8 text3 text6 F-C-B text9 text12 text10 text13 text11 Note that there is no f-c-b at the end, so the columns are not balanced. Together with inline objects which can span several columns that should do the trick for headline, what do you think? I could also allow changing the # of columns at a f-c-b if required. /Andreas |
|
|
thx guys for this discussion |
|
|
Sorry for reopening, but I have a - perhaps - stupid question: Is there anything discussed here that couldn't be achieved by extended table features? IMHO, a better implementation of tables would solve many if not all issues mentioned. So perhaps we should focus on discussing table features -- in a separate rfe, of course. |
|
|
Christoph, I re-read the whole thread. I am still not too sure about the column paragraph option while at the same time I see many use for this. So I basically stick to my first reaction about this idea. My take: if Andreas or any developper has time to look into this (I have *no* idea of what is involved here) I would gladly test this new approach, moreover if it is treated like part of the paragraph style. At the same time, I would keep this for further development. I see lots of work ahead and I don't think the column issue as a paragraph option is a high priority. Not in my view anyway. Tables are another story. But I hardly have something to say about them because I have never worked seriously with tables in any DTP apps. If we want to dig into this, I would welcome a new bug report more specific on tables. This would draw the attention of people who use tables extensively. |
|
|
Still a wont fix.. it wont change.. let it die. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-02 07:53 | mhanski | New Issue | |
| 2006-05-02 07:54 | mhanski | Relationship added | related to 0003266 |
| 2006-05-02 08:01 | mhanski | Status | new => feedback |
| 2006-05-02 08:16 | louisdesjardins | Note Added: 0010769 | |
| 2006-05-02 16:28 | mkoren | Note Added: 0010792 | |
| 2006-05-02 17:20 | cbradney | Note Added: 0010794 | |
| 2006-05-03 03:57 | louisdesjardins | Note Added: 0010823 | |
| 2006-05-03 08:31 | pingu | Note Added: 0010829 | |
| 2006-05-04 14:42 | pingu | Note Added: 0010889 | |
| 2006-05-04 16:32 | mkoren | Note Added: 0010897 | |
| 2006-05-04 17:17 | mkoren | Note Added: 0010903 | |
| 2006-05-05 00:14 | christoph_s | Note Added: 0010947 | |
| 2006-05-05 09:02 | pingu | Note Added: 0010960 | |
| 2006-05-05 09:05 | pingu | Note Edited: 0010960 | |
| 2006-05-05 11:29 | louisdesjardins | Note Added: 0010964 | |
| 2006-05-05 20:33 | christoph_s | Note Added: 0010984 | |
| 2006-05-07 08:21 | pingu | Note Added: 0011043 | |
| 2006-05-07 11:23 | louisdesjardins | Note Added: 0011049 | |
| 2006-05-07 11:32 | louisdesjardins | Note Edited: 0011049 | |
| 2006-05-07 11:33 | louisdesjardins | Note Edited: 0011049 | |
| 2006-05-08 07:59 | pingu | Note Added: 0011085 | |
| 2006-05-08 08:02 | pingu | Note Edited: 0011085 | |
| 2006-05-16 10:51 | avox | Status | feedback => resolved |
| 2006-05-16 10:51 | avox | Resolution | open => won't fix |
| 2006-05-16 10:51 | avox | Assigned To | => avox |
| 2006-05-16 10:51 | avox | Note Added: 0011325 | |
| 2006-05-16 16:09 | mhanski | Status | resolved => closed |
| 2006-05-16 16:09 | mhanski | Note Added: 0011329 | |
| 2006-12-23 14:36 | christoph_s | Status | closed => feedback |
| 2006-12-23 14:36 | christoph_s | Resolution | won't fix => reopened |
| 2006-12-23 14:36 | christoph_s | Note Added: 0014197 | |
| 2006-12-23 22:09 | louisdesjardins | Note Added: 0014207 | |
| 2006-12-23 23:27 | cbradney | Status | feedback => closed |
| 2006-12-23 23:27 | cbradney | Note Added: 0014211 | |
| 2006-12-23 23:28 | cbradney | Resolution | reopened => won't fix |
| 2007-03-24 23:16 | christoph_s | Relationship added | duplicate of 0005481 |
