Subject: Re: commit: Fix all known section break and column break bugs.
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Aug 27 2001 - 00:46:50 CDT
On Sun, 26 Aug 2001, Paul Rohr wrote:
> At 09:08 AM 8/27/01 +1000, Martin Sevior wrote:
> >Full multi-column support. Column breaks are correct now. You have
> >multiple rows of columns from the same section on the same page.
>
> Snazzy screen shot! Is this kind of effect triggered by the markup somehow,
> or is it automatically calculated?
>
> I guess what I'm asking is how does the user indicate whether they want two
> rows of columns on the page or just one? Previously, the way to get this
> effect was to put a continuous section break between the first row and the
> second.
This was a bug reported as such in bugzilla. If you placed a column break
in the last column of your row you effectively got a page break.
Now the cursor is placed in the first column of the row immediately
underneath the lowest point of text in the precing row.
(The same technique could be used to get the journal-style look of
> a single-column intro followed by a two-column document body.)
Yep. I used that technique to generate my Letter Head.
> I'm pretty
> sure that a technique like that would be compatible with the way this is
> done in other WP file formats.
>
Yes all this still works. In fact now you don't get segfaults if you edit
these thing too :-)
> Are you still doing it that way, or is there some new markup to learn?
>
Both work. Neither segfault. At least the hairy stuff I've thrown at it
doesn't segfault it.
> >I put a spin button on the Columns dialog to allow arbitary numbers of
> columns.
> >I plan to enable control of the "Space After column" Section property in
> >this dialog too.
>
> Sweet. Will we need to widen the preview to make it look prettier?
>
I was thinking of making thre view honour the aspect ratio of the current
page style. Many columns is mostly use for landscape layouts. Particularly
for posters. See later.
> >I'm thinking of putting in a new section-level property "Maximum column
> >height" so that columns will automatically break at the height you set
> >
> >See: http://seviorpc.ph.unimelb.edu.au/abiword/multicolumns.jpg
> >For a cool screen shot :-)
>
> That's an interesting effect. Do you have any idea whether we'll be able to
> make it survive a round trip through other file formats, or would it be an
> AbiWord-only feature?
I'll check RTF and see if RTF has a property like maximum column height.
I'd like to implement it so that I can use Abiword to generate Poster.
I'll set the page size to A0, set the Column height to something
reasonable and get a nice retangular array of pages to fill. :-)
>
> >I believe this is 100% correct right now. However I would really
> >appreciate feeback on the various bugs in bugzilla. In addition I think
> >the code you be speeded a up a bit as for some reason, multi-redraws are
> >being triggered sometimes.
>
> Awesome! I love it when people can feel free to really beat on a feature.
> :-)
>
> >Anyway, enjoy our new few feature. Coding this has really helped me
> >understand how to do the hard parts of tables.
> >
> >Once 1.0 is out I think tables will come pretty quickly.
>
> Excellent. Does this mean that you've got the formatter tuned up enough to
> handle all the screw cases of nested tables and cells spanning rows and
> columns? Aside from all the UI quirks (navigation, etc.), those are some of
> the worst aspects of table formatting.
Nope :-)
I think I can handle just tables pretty easily. For tables we just lay
paragraphs out into cells of specified widths. Once this is done we know
the heights of all the cells and we can use something like the gtk
bounding box mechanism to assemble these into a rectangular table. The
table gets placed on the screen and the columns are laid down before and
after it. The code to handle the columns growing and shrinking as the
table resizes or is moved up and down the text is done now. So pure tables
should not be too difficult to layout.
Frames are more difficult. I guess Eric (?) implemented this really neat
method called bumpLines which can quickly bump lines between columns by
just reparenting them. We can't do this in the columns around a frame
because we can't assume the columns in a section are all the same width.
There will have to be some interaction between formatting a paragraph
into lines and the location of the lines on the screen. Bumplines will
have to also have an reformat paragraph possibility.
We can't avoid some clashes between the physical layout classes fp_* and
the logical layout classes fl_* for Frames. This is inevitable because
Frames explicitly assume some relationship to location on page.
I think this can be solved. I see the direction to go.
Cheers
Martin
This archive was generated by hypermail 2b25 : Mon Aug 27 2001 - 00:47:00 CDT
