The Quarterly Report That Shifts Between Printers
You are finalising a 24-page quarterly report in a word processor. The document uses Heading 1 for chapter titles, and you have manually inserted a page break before each chapter heading instead of using a paragraph property. The report contains 14 tables, and three of them are wider than the text column, so you have dragged their right borders inward by hand. Margins are 2.5 cm all round. When a colleague opens the file on a laptop, the three wide tables now spill onto a second page, and two chapter headings sit at the bottom of a page with only one line of text beneath them. The file must be shared as an editable document with the finance team, who will add figures next week.
1. Diagnose why the layout shifted on the colleague's machine and state the two structural changes that would make the layout stable.
Read the worked answer
The shift is caused by manual formatting that depends on the current rendering rather than on document structure.
- Manual page breaks before headings are fixed objects. If content above them grows or shrinks (a wider table, a different default font), the break stays put but the surrounding flow does not, so headings can end up stranded at a page bottom.
- Dragged table borders set a fixed width in the current unit/environment. On another machine, the available text width can differ (different default paper size, different font metrics), so the fixed width no longer fits and the table wraps to a second page.
The two structural fixes:
- Replace manual page breaks with "page break before" set on the Heading 1 paragraph style, so the break is owned by the style and applies to every chapter automatically.
- Replace dragged borders with table autofit to the text column (or set a percentage width), so the table resizes with the page rather than holding a fixed width.
A secondary safeguard is to keep the heading with the following paragraph ("keep with next") so a heading can never be orphaned.
2. The finance team will edit the file and return it. What single formatting decision reduces the chance of layout drift when they add rows to tables?
Read the worked answer
Set the tables to autofit to contents/window with a percentage width, and apply the same table style to all 14 tables.
Reasoning: the drift comes from tables that cannot grow gracefully. A fixed-width table that gains a row or a longer number forces a reflow that pushes neighbouring content. A percentage-width table with a consistent style absorbs added rows without changing its footprint relative to the text column, and a shared style means the team's edits inherit the same borders, padding, and header formatting instead of picking up local overrides.
Do not rely on "it looked fine on my screen" - that is exactly the condition that failed in the setup.