Michael, > I'd like to see functionality like this too. You can't do it at the moment, > and as Louis mentioned, there was some controversy on the bugtracker over > whether to support it in the future. But the discussion there was on making > # of columns a paragraph level property, which (as was realized then) could > cause some problems, and wouldn't really do what you want. > > I think a nice solution would be "frame subdivisions," where a frame could > be subdivided vertically into separate regions, just like it is divided > horizontally into columns now. I imagine a single unified subdivision scheme > for frame sections and columns, as well as tabs and indentation levels and > maybe even the new table implementation. There could be a nice general > algorithm which supports explicit subdivisions of a region into n sections
> (like columns) as well as subdivision breaks in the text itself, which is > what you would need here. > > Each subdivision of a frame could have its own frame-level properties, > including # of columns (horizontal divisions) within it, etc. If I understand your description, it sounds like you advocate a floating table. As I was trying to work with columns in my sample text, I began to wonder if what I was looking for was somehow implemented in a tables feature that I was not seeing. So I think having the option of subdividing frames or a floating table feature makes more sense than making columns a paragraph level property. The former addresses layout; the latter, style. I am comparing this idea to how HTML tables are best used in conjunction with CSS. Yes, both CSS and paragraph properties affect layout, even significantly. But when you want to compel the text to flow and re-flow with rows and columns intact, using "frame subdivisions" or a floating table makes sense. > This part would need support for setting column widths and gaps individually > (which is currently requested as bug #162). There could be support for this > as part of a general subdivision scheme, including fancy features such as > specifying which values or relationships to preserve when the frame or other > widths are resized. > > Here is the way I would imagine doing what you want to do overall: > > 1) set an indentation or tab stop for the main frame (optional, so you could > resize it easily later) > 2a) define your style for paragraphs 1 and 4 to use the frame's indentation > setting for the hanging indent, or > 2b) just apply a hanging indent in the text without using a style if that > becomes supported > 3) put subdivision breaks after paragraphs 1 and 3 and set the second > subdivision to have 2 columns > 4a) set your column spacing using a slider thingy (like the one for tabs) to > look something like this: Yes, I would like a slider to set column spacing > [gap] [col] [gap] [col] > X 50% 36 pt 50% > > where the first gap is locked to the frame's first indentation level, and > the column widths are percentages of the remaining space after the fixed > gaps. Although this is how a word processor might handle it -- and, incidentally, it really bugs me that MS Word can do the 1-2-1 column thing, save for the hanging indent, better than page layout software -- percentages are most useful in determining the layout of web pages because we place a value on allowing the user to modify how the browser presents the content. I wonder how useful percentages would be for print/PDF page layout, where the typographer presents unalterable content to the reader. > 4b) optionally save this as a column style for reuse throughout the > document. I absolutely agree that having the option to name and save the frame subdivision for use elsewhere in the story is of equal benefit to having frame subdivisions. In fact, it makes the whole scheme worthwhile. Add a few cell breaks (or column and row breaks) to the story, click the name of the saved frame subdivision, and move on. Though I prefer more precise control of points to percentages, I think you have a great idea here. I wonder if it could be developed as a plug-in, later to be implemented in Scribus when it is debugged? (That would be beyond my abilities.) > Out of curiousity, how did you get past even paragraph one this way? You > can't have it in one column above and paragraphs 2 and 3 in two columns > below it, can you? I didn't realize it until you asked, but the first paragraph was of shorter width than the first column. When I added more text, it wrapped within the first column width. So I didn't achieve even as much as I thought I had. Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20061025/12ca7b3a/attachment.html
