Issue 78772

Summary: Request: Single page margin overrides/Automatic styling
Product: Writer Reporter: floid <itsafloid-privacyguard>
Component: formattingAssignee: michael.ruess
Status: CLOSED DUPLICATE QA Contact: issues@sw <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: OOo 2.0.2   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description floid 2007-06-21 17:56:00 UTC
Another quirk from a legal office migrating from Corel Wordperfect:

Sometimes widow/orphan control isn't enough (or convenient enough), and upon
finalizing a document or letter, the easiest thing to do is 'cheat' and lower a
margin to avoid an orphan on the next page.

In OO.o, dragging the margin on the ruler changes the margin for the page style.
 This is consistent but surprising and not always desired -- reformatting all
members of a style forces the user to reexamine the entire document for widows,
orphans, and other formatting quirks.  A very common case that widow/orphan
control won't pick up without some user attention and skill: section titles in a
document (_This_Is_the_Rent_Clause_of_a_Lease_) that were followed by paragraph
breaks -- AKA 'hitting enter.'

Ideally it would be possible, with minimal fuss (e.g. shift-drag?  Or if the
existing behavior is rarely intended, perhaps this should be default and a shift
or control combination should be required to modify the existing style?) to
emulate the Corel behavior.

A couple ways this could be implemented:

* Dragging the margin inserts a special override code anchored to the page. 
Ideally this is very visible when editing.

* Dragging the margin creates and applies a new page style, inheriting the other
properties of the original style and 'followed by' same original.  Problem:
naming conventions ("Automatic Margin Override Style 1?"); Advantage: sort of
consistent with the style metaphor, could allow one tweak to be reused as needed
for some consistency.


Unfortunately (non-obviously) this override behavior would have to be
implemented again with regard to header/footer heights, as if a header or footer
is present, it should really stay anchored to the same position (fixed distance
from top or bottom of page in user's mental model, defined as the top or bottom
margin in OO.o) and adjusting its 'height' is then what adjusts the size of the
text area of the page.


I hope someone will consider this, because the current behavior (user drags
margin to fix one widow/orphan, all pages of style reflow, user is too surprised
at perceived loss of work -- loss of time spent formatting -- to realize that
editing the style will 'fix' it, user attempts to strangle nearest IT worker) is
causing extreme stress at our organization. ;)
Comment 1 michael.ruess 2007-06-22 08:11:28 UTC
Already tracked as issue 4624.

*** This issue has been marked as a duplicate of 4624 ***
Comment 2 michael.ruess 2007-06-22 08:12:54 UTC
Closing duplicate.