[Scribus] Single text frame with one, then two, then one column(s)
Wed Oct 25 18:15:38 CEST 2006
Alt 033 a ?crit :
> > I'd like to see functionality like this too. You can't do it at the
> > and as Louis mentioned, there was some controversy on the bugtracker
> > whether to support it in the future. But the discussion there was on
> > # of columns a paragraph level property, which (as was realized then)
> > cause some problems, and wouldn't really do what you want.
> > I think a nice solution would be "frame subdivisions," where a frame
> > be subdivided vertically into separate regions, just like it is divided
> > horizontally into columns now. I imagine a single unified subdivision
> > 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
> > (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
> > (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
> > setting for the hanging indent, or
> > 2b) just apply a hanging indent in the text without using a style if
> > 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,
> > 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.
> > 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.
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
T 514 934 1353
F 514 934 3698
More information about the scribus