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

[Michael Koren]

Hi, I didn't see all the replies at first. I'm glad people found the idea
interesting.


Louis Desjardins-2 wrote:
> 
> Alt 033 a ?crit :
> 
>> Michael,
>> 
>>  > 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.
>> 
> 

Interesting. I've been meaning to learn HTML and CSS at some point--I'm
interested in different ways of organizing and formatting content. I
definitely think this is related to some kind of table concept. I know
tables are being totally redesigned for 1.3.4, but I don't know the details
of the current plan.



>>  > 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.
> 

Percentages would be for simple things like "I want three equal-sized
columns in the frame, no matter how big it is"--essentially what we already
have, with a little more flexibility. That way, like in your case, you could
keep the columns equal even if you resize the frame or the page, but yet
maintain, say, a given fixed indentation size and gap.

But my idea was to support both for maximum flexibility. Which has left me
trying to figure out the easiest way to combine fixed and
percentage-oriented subdivisions in a generic algorithm that would apply to
columns, frame divisions, indentation settings, and tabs (subdivision within
a column) without making a mess. :)

For instance, I can imagine wanting this:

XX  XXXXX | XX  XXXXX
XX  XXXXX | XX  XXXXX

i.e., 2 equal larger divisions, each containing a fixed width "margin"
column and a floating second column, or this:

XX  XXXX | XX  XXXXXXXX
XX  XXXX | XX  XXXXXXXX

where the whole first part itself must be a fixed width, and the final
column floats to the remaining width of the frame.... :)

Which led me to think plugins, as you mentioned below. I can post my
thoughts on a basic algorithm for discussion when I get them finished.



>>  > 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.
> 

Exactly.


 
>> 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.)
> 

I wanted to work out a basic subdivision algorithm and see if I could
implement it in 1.3.3.x for tabs and indentation stops (of course I haven't
looked at the relevant code yet :). I would include plugin support for more
sophisticated subdivision algorithms if it looked useful.

The rest couldn't happen until 1.3.4+ with the new file format, but I had a
plan for a workaround using enhancements to inline text frames. :) But I
have no idea when I'll get around to it, and I can't promise anything!



> 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.
> 

Absolutely! :)



> Louis
> 
>> Ron
> 

Michael
-- 
View this message in context: http://www.nabble.com/-Scribus--Single-text-frame-with-one%2C-then-two%2C-then-one-column%28s%29-tf2508521.html#a7150576
Sent from the Scribus mailing list archive at Nabble.com.