Issue 60686

Summary: The logic of "keep with next paragraph" is defective
Product: Writer Reporter: raindrops <na1000>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 2.0.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
Sample shows problem none

Description raindrops 2006-01-17 08:42:29 UTC
NOTE: I had posted this problem as Issue 60632. But while creating a sample
document for that issue, I realized that the problem was more general. Rather
than attaching the new description in that issue, I am opening a new issue.

The attached document demonstrates problems with "Keep with the next paragraph"
property of a paragraph.

In the document, I have done the following preparatory work:
1.Created three paragraphs named para1, para2 and para3.
2.selected Keep with the next paragraph for para1 only. The other two paragraphs
are normal.
3.I have entered blank lines below this description to position the paragraphs
near the page-break.

1.If we click in the blank space below the horizontal ruler and insert/delete
lines (by pressing Enter and Delete, respectively), the para1 stays with para2
(this is OK). 

2.But if we click on the left of para1 and press Enter, its Keep with the next
paragraph attribute gets reset. (This is a defect, because a paragraph's
properties should not change when we press Enter at its beginning.)

3.In fact, there is another (related) defect: If we split para1 (by clicking
anywhere in it and pressing Enter), the Keep with the next paragraph attribute
of the second part gets reset. This is totally illogical: In our original
scheme, para1 was supposed to stay with para2. If para1 is split, both split
parts now stay together, and para2 is abandoned!
Compared to that, any of the following arrangements would be more logical:
a)Both parts of Para1 have the Keep with the next paragraph attribute selected,
(in other words, both parts of para1 stay with para2.)
b)Only the second part of para1 has the Keep with the next paragraph attribute
selected, (In other words, only the second part of para1 stays with para2.)

In fact, leave this choice to the user in Program options.
Comment 1 raindrops 2006-01-17 08:45:47 UTC
Created attachment 33294 [details]
Sample shows problem
Comment 2 michael.ruess 2006-01-17 14:16:55 UTC
It is intended, that a new paragraph will not overetake the "keep" attribute
from its preceeding paragraph. By this, it should be prevented too many
successive paragraphs having the "keep" attribute, which does not make sense
(how should Writer know, which of these many paragraph should be kept together).

But: aspect 2 is quite correct. We should have a specil treatment for the case,
the cursor is placed in the first position of a paragraph. In this case, for the
user it is like moving the paragraph down, so the "keep" attribute should be
moved to the new paragraph.
Comment 3 raindrops 2006-01-18 08:15:34 UTC
Raindrops -> mru

Well, I have different understanding about issue-3. Let us explore different
aspects of this particular issue:

Question1: Just WHAT are we trying to keep together?

If we say "keep para1 together with para2", the reason is this:
"The end of para1 is very closely linked with para2; and therefore they must not
be separated."

This is important: Our SOLE objective is to maintain the attachment with para2.

In other words, the command is supposed to act on TWO paragraphs; not on a
SINGLE paragraph. It is NOT a standing instruction to Writer that "This
paragraph contains closely knit concepts. If it is ever split, please keep the
parts together."

In fact, Writer does not have a provision like that.

Question2: Can I separate para1b and para2?

Answer2: In short, NO. See the reasons below--

We had asked Writer to keep para1 with para2.
Why? Because the tail end of para1 dovetails into para2 nicely.

And when we split para1 into para1-a and para1-b, para1-b is same as the TAIL
end of the erstwhile para1. 

So the equation set earlier is not affected: After the split, we MUST keep
para1-b and para2 together.

In other words, the "Keep with the next paragraph" property MUST be passed over
to para1-b.
Question3: "Why not keep para1-a and para1-b together? After all, they WERE
parts of a single paragraph!"

Answer3: In Writer, splitting a paragraph is routine. It does not require
keeping the parts together.

And so it is with para1-a and para1-b also: They are just two paragraphs in the
document. Why should Writer treat them as a special case and try to keep them

Question4. What will happen if we wanted to keep all parts of para1 together?

Answer4: First of all, as answer#1 shows, the focus is on attachment with para2. 
Further, Answer#1 also shows that split parts of para1 are independent
paragraphs. Writer must NOT try to keep them together; as that would be
overstepping the intentions of the user.

But IF done, this does NOT pose any risk. To begin with, very few paragraphs
will have this attribute enabled. Secondly, even if the user splits such
paragraphs, the total length of such paragraphs cannot exceed a page's length.
(It would be logically impossible for the Writer to keep together paragraphs
that run more than a page's length!) So, after a page, Writer would
automatically ignore the property.

So we can go ahead and keep all parts together, PROVIDED THAT we do not lose the
the focus from para2!

Finally, a thought: The way I have recommended, point-2 and point-3 seem to be
identical: In both, we press ENTER at the beginning of a paragraph and expect
that the paragraph BELOW to have the "Keep with the next paragraph" property.
Comment 4 frank.loehmann 2006-01-19 10:01:40 UTC
FL: Thank you for your detailed explanations and I understand your need and I am
sure that this will work for you and people with detailed understanding of word
processing. But our experience with normal users shows us that those do not know
anything about those invisible attributes and their impact on the document
formatting. That is why this attribute will not be copied to the next paragraph
on pressing return. 

Let me give you an example seen many times in usability tests we have made:
People don't know about spacing before and below a paragraph and have no clue
how to get rid of these spaces, as they format using blank paragraphs to add a
spacing between paragraphs. This behavioral pattern did   become a problem in
OOo 1.1 where numberings started over (beginning with 1.) again if the numbering
has been turned on after inserting an empty paragraph to add a spacing between
two paragraph of a numbering. We also had similar issues were those invisible
attributes have been extended all over the document i.e. the end mark of a
document's index where many people did extend the index on the last paragraph of
the index to write their document and so the non visible attribute got copied
across the whole document. On updating the index, the whole document content was

This is the reason why we are not planning to change this behavior. I propose to
introduce a visual indicator in front of the paragraph, showing up when the
nonprinting characters are turned on and the paragraph has the keep with next
Comment 5 raindrops 2006-01-19 12:21:56 UTC
I see! 

At least point-2 should be taken care of, because that is consistent with the
general handling of paragraphs. (When you click in its beginning and press
Enter, it should not reset the "keep..." property.)

Comment 6 frank.loehmann 2006-01-19 14:19:19 UTC
FL: I am in doubt. It depends on the content of paragraph 1b, if this paragraph
will still belong to #2. Furthermore I have seen another problem quite regularly
in tests: If a paragraph ends with a space i.e. "...over the lazy dogs back. "
which happens often automatically when typing the dot, then a later entered
return in front of that space (because it is invisible in the UI) would be a
splitting of that paragraph and so would take this space an it's attributes to
the next paragraph and to the next...

I think this could be solved by a better interactive UI representation in the
document, but this is currently not on the list for OOo 3.0.

What I can support is a visual indicator for "keep together" paragraphs, so that
it is easier to see where this attribute has been set. So if you please would
write me an issue for this, I would accept it and set the target to OOo 3.0.
Comment 7 raindrops 2006-01-20 07:35:09 UTC
Now I get it-- As I observed in the earlier post, points 2 and 3 are identical;
and therefore if point 3 is not advisable (for usability reasons), even point 2
also should be avoided.

Yes I agree. 

It would be appropriate to dispose of this issue as "wontfix".

I'll raise an issue for a visual indicator.

Many thanks for providing such a beautiful insight into the usability issue!