[Scribus] Single text frame with one, then two, then one column(s)

Louis Desjardins louis_desjardins
Wed Oct 25 18:15:38 CEST 2006


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



More information about the scribus mailing list