Re: [Bug 2269] Changed - Column break functionality


Subject: Re: [Bug 2269] Changed - Column break functionality
From: Phil Stracchino (alaric@babcom.com)
Date: Mon Nov 26 2001 - 15:28:09 CST


On Mon, Nov 26, 2001 at 12:09:36PM -0600, bugzilla-daemon@abisource.com wrote:
> + ------- Additional Comments From cinamod@hotmail.com 2001-11-26
> + I think that you misunderstand what columns are. They're just logical breakdowns
> + of a page. The behavior that you explain is quite intentional, because it's
> + quite normal to want multiple columns on the same page. The hitting of column
> + break in the second column has the effect of creating a new column _underneath_
> + your first column. If you wish to break onto a new page, use page break or
> + column break + page break instead. Closing.
> \ No newline at end of file

I understand perfectly well what columns are. This is the first time I
have ever seen any word processor behave in the manner you are describing
as normal, and what your comment that "If you wish to break onto a new
page, use page break or column break + page break instead" tells me is
that you didn't follow what I was saying. In the interest of clarity,
it's ASCII art time. I am cc'ing this to the user list because I'd like
to hear other users' opinions regarding how column breaks should work.

Suppose I have three pages of a document, each divided into two columns.
In each column, I want a single block of text to appear, like so:

[1]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 44444444 | | 55555555 66666666 |
| 111111111 222222222 | | 333333333 444444444 | | 555555555 666666666 |
| 111111111 222222222 | | 333333333 444444444 | | 555555555 666666 |
| 111111111 222222222 | | 333 444444444 | | 555555555 66666666 |
| 111111 222222222 | | 33333333 4444444 | | 555555555 66666 |
| 11111111 2222 | | 333333333 44444444 | | 555555555 66666666 |
| 111111111 2222222 | | 333333333 444444444 | | 555555555 666666666 |
| 111111111 222222222 | | 333333 4444444 | | 555555555 666666666 |
| 111111111 222222222 | | 33333333 44444444 | | 555555555 666666666 |
| 111111111 222222222 | | 333333333 444444444 | | 5555 666666666 |
| 111111111 222222222 | | 333333333 44444 | | </col> 666666666 |
| 111111 22222 | | 33333 </col> | | 6666666 |
| </col> </col> | | </col> | | </col> |
| | | | | |
 --------------------- --------------------- ---------------------

The way column breaks work now, if the blocks of text in each column are
large relative to the height of the page, I get what I want. However, if
some of them are small relative to the height of the page, then all of a
sudden I get this:

[2]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 44444444 | | 66666666 77777777 |
| 111111111 222222222 | | 333333333 444444444 | | 666666666 777777777 |
| 111111111 222222222 | | 333333333 444444444 | | 666666 777777777 |
| 111111111 222222222 | | 333 444444444 | | 66666666 77777 |
| 111111 222222222 | | </col> 4444444 | | 66666 77777777 |
| 11111111 2222 | | </col> | | 66666666 777777777 |
| 111111111 2222222 | | | | 666666666 77777777 |
| 111111111 222222222 | | 55555555 555555555 | | 666666666 77777777 |
| 111111111 222222222 | | 555555555 5555 | | 666666666 777777 |
| 111111111 222222222 | | 555555555 </col> | | 666666666 </col> |
| 111111111 222222222 | | 555555555 | | 666666666 |
| 111111 22222 | | 555555 | | 6666666 |
| </col> </col> | | 55555555 | | </col> |
| | | | | |
 --------------------- --------------------- ---------------------

You're saying I can force the behavior I want by using column break plus
page break, like so:

[3]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 44444444 | | 55555555 66666666 |
| 111111111 222222222 | | 333333333 444444444 | | 555555555 666666666 |
| 111111111 222222222 | | 333333333 444444444 | | 555555555 666666 |
| 111111111 222222222 | | 333 444444444 | | 555555555 66666666 |
| 111111 222222222 | | </col> 4444444 | | 555555555 66666 |
| 11111111 2222 | | </page> | | 555555555 66666666 |
| 111111111 2222222 | | | | 555555555 666666666 |
| 111111111 222222222 | | | | 555555555 666666666 |
| 111111111 222222222 | | | | 555555555 666666666 |
| 111111111 222222222 | | | | 5555 666666666 |
| 111111111 222222222 | | | | </col> 666666666 |
| 111111 22222 | | | | 6666666 |
| </col> </col> | | | | </col> |
| | | | | |
 --------------------- --------------------- ---------------------

And so I can, up to a point. But now observe what happens if I later need
to insert a new block between blocks 3 and 4:

[4]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 3a3a3a3a | | 44444444 |
| 111111111 222222222 | | 333333333 3a3a3a3a3 | | 444444444 |
| 111111111 222222222 | | 333333333 a3a3a3a3a | | 444444444 |
| 111111111 222222222 | | 333 3a3a3a3a3 | | 444444444 |
| 111111 222222222 | | </col> a3a3a | | 4444444 |
| 11111111 2222 | | 3a3a3a3a | | </page> |
| 111111111 2222222 | | 3a3a3a3a3 | | |
| 111111111 222222222 | | a3a3a3a3a | | |
| 111111111 222222222 | | 3a3a | | |
| 111111111 222222222 | | 3a3a3a3a | | |
| 111111111 222222222 | | 3a3a3a | | |
| 111111 22222 | | </col> | | |
| </col> </col> | | | | |
| | | | | |
 --------------------- --------------------- ---------------------

or [4a]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 3a3a3a3a | | 55555555 66666666 |
| 111111111 222222222 | | 333333333 3a3a3a3a3 | | 555555555 666666666 |
| 111111111 222222222 | | 333333333 a3a3a3 | | 555555555 666666 |
| 111111111 222222222 | | 333 3a3a3a3a | | 555555555 66666666 |
| 111111 222222222 | | </col> 3a3a3a3a3 | | 555555555 66666 |
| 11111111 2222 | | a3a3a3 | | 555555555 66666666 |
| 111111111 2222222 | | </col> | | 555555555 666666666 |
| 111111111 222222222 | | 44444444 | | 555555555 666666666 |
| 111111111 222222222 | | 444444444 | | 555555555 666666666 |
| 111111111 222222222 | | 444444444 | | 5555 666666666 |
| 111111111 222222222 | | 444444444 | | </col> 666666666 |
| 111111 22222 | | 4444444 | | 6666666 |
| </col> </col> | | </page> | | </col> |
| | | | | |
 --------------------- --------------------- ---------------------

If I have many pages with short items in each column, then every time I
insert a new block in mid-document, I will have to go through the whole
document and manually fix the page breaks on every subsequent page. This
is flat-out *WRONG*, period. What's worse, even simply deleting a line or
two from block 3 or 4 can suddenly cross AbiWord's threshold for starting
a "new column below the existing columns" as in figure 2. I could
conceivably do a global search and replace of a long phrase with a shorter
one, print my document or send it off to a client, and discover too late
that entire sections of my document have been reformatted without my
knowledge. This is *BAD*.

If, on the other hand, I have a 'break to clear column' tag, and I have
used clr-column breaks throughout this section of my document, then I get
this:

[5]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 3a3a3a3a | | 44444444 55555555 |
| 111111111 222222222 | | 333333333 3a3a3a3a3 | | 444444444 555555555 |
| 111111111 222222222 | | 333333333 a3a3a3a3a | | 444444444 555555555 |
| 111111111 222222222 | | 333 3a3a3a3a3 | | 444444444 555555555 |
| 111111 222222222 | | </clr> a3a3a | | 4444444 555555555 |
| 11111111 2222 | | 3a3a3a3a | | </clr> 555555555 |
| 111111111 2222222 | | 3a3a3a3a3 | | 555555555 |
| 111111111 222222222 | | a3a3a3a3a | | 555555555 |
| 111111111 222222222 | | 3a3a | | 555555555 |
| 111111111 222222222 | | 3a3a3a3a | | 5555 |
| 111111111 222222222 | | 3a3a3a | | </clr> |
| 111111 22222 | | </clr> | | |
| </clr> </clr> | | | | |
| | | | | |
 --------------------- --------------------- ---------------------

Which is how I *expect* column breaks to behave in every other word
processor I've ever used.

Even if ALL column breaks ALWAYS go to the next clear column, and I'm
doing something such that I *WANT* the behavior of figure 2, then that's
easily obtained using a continuous section break, the way every other word
processor does it, like so:

[6]
 --------------------- --------------------- ---------------------
| | | | | |
| 11111111 22222222 | | 33333333 44444444 | | 66666666 77777777 |
| 111111111 222222222 | | 333333333 444444444 | | 666666666 777777777 |
| 111111111 222222222 | | 333333333 444444444 | | 666666 777777777 |
| 111111111 222222222 | | 333 444444444 | | 66666666 77777 |
| 111111 222222222 | | </col> 4444444 | | 66666 77777777 |
| 11111111 2222 | | </sect continuous> | | 66666666 777777777 |
| 111111111 2222222 | | 55555555 555555555 | | 666666666 77777777 |
| 111111111 222222222 | | 555555555 555555555 | | 666666666 77777777 |
| 111111111 222222222 | | 555555555 5555 | | 666666666 777777 |
| 111111111 222222222 | | 555555555 </col> | | 666666666 </col> |
| 111111111 222222222 | | 555555555 | | 666666666 |
| 111111 22222 | | 555555 | | 6666666 |
| </col> </col> | | 55555555 | | </col> |
| | | | | |
 --------------------- --------------------- ---------------------

I have never seen another word processor in which column breaks work the
way they currently do in AbiWord. (I will insert a disclaimer at this
point to the effect that I don't understand at all how WordPervert
handles columns; I've tried on several occastions to use WordPervert
and it simply baffles me. Everything about it just makes my brain hurt.)

The manner in which other Word-like processors format text around column
breaks allows the document to be easily formatted to appear as shown in
figure 6 (the way AbiWord does it at present), in a *known and
user-controllable manner*, without introducing booby-traps later on,
simply by using a continuous section break. AbiWord's current handling of
column breaks does *not* allow the document to be predictably and
controllably formatted as in Figure 5 without adding additional page
breaks as in Figure 3, which introduces the probability of column
formatting errors as in Figure 4 and 4a, which must be checked for and
fixed by hand every time bhat section of the document is edited.

I have a recipe book (of about eighty pages) that I'm in the middle of
updating, and a gaming resource book (of about four hundred pages) that
badly needs updating. Both were originally written in Word. Both are
formatted relying on columns working in the manner I have come to expect
them to work in every word processor I have used. I would *like* to use
AbiWord for the next revisions of both, but AbiWord's column-break
formatting paradigm will create so much extra formatting work for me that
I cannot reasonably do so.

You appear to be strongly opposed to changing AbiWord's column-break
behavior. This is why I suggested adding a second type of column-break
that would force a break to a clear column, as it allows both types of
formatting functionality and would not remove the current functionality.
Another way to achieve the same end would be to add a preference setting
to either allow column folding (i.e, the way AbiWord does it now) or allow
only strict columns (i.e, the way the rest of the world does it). I
suggest that when there are two clearly-defined different metaphors for a
given behavior, the correct one to choose is the metaphor which allows
obtaining the other behavior with the least additional work on the user's
part and with the least adverse effects. (Ideally, this is also the most
intuitive behavior.) Currently, AbiWord's handling of column breaks fails
this test badly.

If the consensus is that AbiWord's current behavior (always fold columns)
is correct, and that nothing should be done to allow the behavior I've
become used to expecting (next clear column), then I suppose I'll just
have to go and find a different program that works the way I expect. It'd
be incredibly sad and ironic if I ended up having to go back to MS Word to
revise my books.

-- 
  *********  Fight Back!  It may not be just YOUR life at risk.  *********
  phil stracchino   ::   alaric@babcom.com   ::   halmayne@sourceforge.net
    unix ronin     ::::   renaissance man   ::::   mystic zen biker geek
     2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)
       Linux Now! ...because friends don't let friends use Microsoft.

----------------------------------------------- To unsubscribe from this list, send a message to abiword-user-request@abisource.com with the word unsubscribe in the message body.



This archive was generated by hypermail 2b25 : Mon Nov 26 2001 - 15:28:14 CST