I’m full of random bits like this, but I’m not really good at pulling details out of things I do which others might not know, so they don’t come out very often. If I were better at that, I’d have more things to write about!

I admit that I’m a crazy Word Pedant™, and will lots of times go overboard on making sure things are done the “right” way. All that said though, there are still new things to discover in it. This is one of those things. With the benefit of hindsight, this is a pretty basic piece of functionality that I probably should have already had a handle on. I do like these settings, and for the type of documentation that I’m doing now, it has a real benefit.

Table Properties

Long story short, we’re after these two checkboxes in the Table Properties dialog:

(The Table Properties dialog is an option on the context menu if you right-click anywhere in a Table, or also the Table Tools | Layout tab of the Ribbon.)

These two options do just what they say they do:

Allow rows to break across pages. This setting is similar to the “don’t let a single sentence of a paragraph sit on a page by itself” setting (which I can’t currently find in Word 2010, so maybe you can’t control that anymore). It comes into play if there’s multiple lines of text in a table cell (or every cell in a row). It will force the whole row to break down to the next page instead of splitting the row contents across a page break.

This is good for the ETL documentation I’m working on these days, because some of the source-to-target mappings that are being documented have some pretty long descriptions and/or script bits to handle conversions & such. In a four or five column table on a portrait Letter page, some of these rows wind up pretty tall. It’s really confusing to read if these long snippets wind up broken across pages. This situation is made worse because all of the other columns’ data is back on the last page, and half of the mapping description is hanging out by itself on page two. It does mean there’s sometimes half a page left blank because of a tall row, but that’s the lesser of evils, in my opinion.

Repeat as header row at the top of each page. (Just to note, this option is also available as a button on the Table Tools | Layout tab of the Ribbon. That part of the Ribbon will show up with the cursor in a table, and this particular option is greyed out unless the cursor is in the first row of a table. That right there is a good illustration of both the blessings and the curse of the Ribbon, but I digress.) This option can be set for one or more rows at the top of the table. When set, these rows will repeat, as they are, at the top of the table as it spans from page to page. This setting is useful for obvious reasons with big tables that span multiple pages.

Example

Making up a table in Word to mimic an ETL source-to-destination mapping document will make a useful example to show what these options will do.

With a table that spans across a page break, the default behavior in Word will yield a table that looks like this:

There are a couple problems with this.The first one is how there’s a row split across pages, leaving the back half of the mapping script sitting by itself on the second page. Obviously if this is printed, the rest of it is on the page you just turned over, so it’s not that far away. If it’s on-screen, it’s even closer—just a quick scroll up. Even so, I think it’s simply better form, if you can, to keep whole rows together to make consumption of the data easier.

Likewise, if looking at just the second page, the column headings aren’t visible. Perhaps not as big of a deal with a small table, or a document where the same general table is repeated throughout, but if the table is large, or perhaps one that spans multiple pages (I’ve had some of those going on recently), it’s very convenient to be able to see the headers on each page. Think of how nice it is to Freeze Panes in Excel.

Enabling the two options discussed above on the same table will result in this table:

Now both problems have been solved. The penultimate row is no longer broken across pages—it now is forced down to the second page in its entirety, easing comprehension of its contents. Additionally, the column headers now repeated on the second page save one’s sanity for obvious reasons.

The repeated header rows are kind of “virtual” rows—you can’t even put your cursor in it. They update in real-time when the actual header row is changed, so they are always correct.

There you have it. Go forth and format tables!