Apache OpenOffice (AOO) Bugzilla – Issue 60686
The logic of "keep with next paragraph" is defective
Last modified: 2013-08-07 14:38:26 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. Experiments: 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.
Created attachment 33294 [details] Sample shows problem
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.
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? Answer1: 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 together? ******* 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.
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 gone. 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 attribute.
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.) Thanks.
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.
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!