Alt 033 a ?crit : > 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.)
This idea of "horizontal" columns (if you allow me to say!) sounds really interesting. I wonder what the devels and other power users think about this. When we have to deal with such a layout, we use as many text frame as needed and simply link them. But there might be a better/easier way of doing that and this might just be it. Not sure, but interesting and worth digging, I think. Louis > > > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Scribus mailing list > Scribus at nashi.altmuehlnet.de > http://nashi.altmuehlnet.de/mailman/listinfo/scribus -- Louis Desjardins Mardigrafe inc. T 514 934 1353 F 514 934 3698 http://www.mardigrafe.com
