7 Steps to Better Tables of Contents in OpenOffice.org Writer
Like other word processes, OpenOffice.org Writer makes creating tables of contents (ToCs) quick and easy. Unfortunately, it also works with unaesthetic defaults and allows you to make choices that complicate your work flow rather than improving it.
Fortunately, Writer is also flexible enough to allow you to produce useful, aesthetic ToCs if you follow a few basic steps.
However, before you read about these steps, you might want to refer to "OpenOffice.org Off-the-Wall: ToCs, Indexes and Bibliographies in OOo Writer," which covers the basics of how to create a ToC. The general procedure is not difficult: first. you create the markers to use in the ToC via Insert -> Indexes and Tables -> Entry -> Index -> Table of Contents, then you generate the ToC through Insert -> Indexes and Tables -> Indexes and Tables. If you want, all you need to do is click the OK button to generate the ToC, but you can customize it in just about every way imaginable, so you might want to refresh your mind about the details before looking at these steps.
Create from outline
Instead of adding your own markers for the ToC, write the document from its very beginning using Heading styles to mark off sections of your work, then select Create from -> Outline as you generate the ToC. You'll not only save time, but help readers to find exactly what you are referring to when they follow a reference in the ToC.
Change the outline numbering if you want to use other styles
Usually, Writer ToCs use Headings 1 through 10 paragraph styles. If you want to include a Title, SubTitle, or Chapter Style in the ToC automatically, go to Tools -> Outline Numbering and change the paragraph style for the first and maybe the second level headings.
Limit yourself to 3 levels of headings
Old engineering documents often had half a dozen heading levels or more. Many heading levels are a document designer's nightmare, because there are only so many ways to differentiate headings - - chiefly typeface, size, indentation -- and using all the possible connections quickly looks cluttered.
Even more importantly, keeping track of where you are in the document is nearly impossible.
Three is a rather arbitrary number of headings, but it is usually enough to organize your document without being confusing aesthetically or practically. And that's three in total, including any title, sub-title, or chapter title that will be listed in the ToC. If you think that a subject needs more headings, ask yourself whether a re-organization can keep the number down -- almost always, it will.
Protect against manual changes
On the Index/Table tab for generating ToCs, you will find a check box labeled "Protect against manual changes." Always check this box. It will force you to work through styles and Writer's other automated features. At first, if you aren't in the habit of using styles regularly, you may think that this work flow is a nuisance, but you will soon find that it helps you regularize your work habits. Besides, if you make manual changes, you will lose them every time you update the fields in your documents and have to redo them. Edit the Contents styles instead (see below).
Avoid dot leaders
Dot leaders are the characters (usually periods) that separate the ToC entry from the page number on the right side of the margin. For some reason, dot leaders have become standard in word processor ToCs, despite the fact that professional typographers generally avoid them. As Robert Bringhurst writes in The Elements of Typographic Style, "Dot leaders (lines of dots leading the eye from one word or number to another) are rarely beneficial in tables." They are both ugly and inefficient.
The reason that dot leaders are seen as necessary is that the page number is always on a tab aligned to the right, which places the page number against the right margin. Most of the time, this position is so far from the ToC entry it refers to that you can hardly see the relation between the page number and the entry, especially in a crowded ToC.
The simplest way to eliminate any need for dot leaders is to change the tab setting. Go to the Entries tab, and select the first level of heading. Find the Tab stop building block for the entry, and set the fill character to a blank (it's hard to see, but at the top of the combo box). Then uncheck the Align Right box, and add a small tab -- no more than two or three centimeters -- and click the All button to apply your changes to all levels of headings. Now, when you generate the ToC, the page numbers will be close to the entry, and you will have no need for dot leaders.
Alternatively, if you find the result unaesthetic (as I do), consider placing the page number first in the entry. Follow the page number building block with a tab and the Entry, and click the All button. The result is not only easy on the eye, but has the advantage of placing the information that you really want when looking at the ToC -- the page number -- first.
Avoid unnecessary decoration
Eliminating unnecessary formatting is a major element in professional design. Just as dot leaders should be avoided because you can do without them, so should any other formatting that doesn't serve the purpose of helping readers use the ToC. For this reason, I suggest avoiding altogether the Column and Background tabs for ToCs.
Multiple columns rarely make reading ToCs easier -- particularly when the page number is to the right of the entry -- because they can force a long entry to spill over into two lines and slow down reading. Sometimes, you may be tempted to use multiple columns so that the ToC takes up less room, but, even then, more than two is going to look sloppy unless you greatly reduce the font size.
In the same way, an unusual background color is only going to call undue attention to itself and do nothing to make the ToC more readable. You don't need it, so leave it out.
Edit contents styles
ToC entries use the Contents paragraph styles. If you look at the Hierarchical view of styles in the Styles and Formatting floating window, you will see that these styles are the children of the Index style, which in turn is the child of the Default style. In other words, the default ToC is going to look much the same as the rest of your document.
This resemblance is not a bad thing. After all, common formatting shows that two pieces of text are related. However, some changes in formatting, such as a change in text size, may be practical. Others, such as the use of a different font weight or another typeface, can make the ToC easier to identify at a glance.
For such reasons, you might want to edit the Contents styles used in your ToC. These styles will appear in the Styles and Formats listing after you generate the ToC for the first time. Editing these styles is quicker than manual editing, and any changes won't be lost when you update the ToC.
Use Writer's defaults for ToCs, and you risk looking design-illiterate. Modifying them will take time, but the result will be a document that is better-looking and more useful to your readers.
Still, nobody likes to do the same work over and over again. Instead, make your changes to ToC structure in your most basic template -- the one that you base other templates on. Then, you can make the changes once and, with luck, never have to edit them again.
-- Bruce Byfield (nanday)
|Android Candy: Copay—the Next-Generation Bitcoin Wallet||Sep 03, 2015|
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- The True Internet of Things
- September 2015 Issue of Linux Journal: HOW-TOs
- Android Candy: Copay—the Next-Generation Bitcoin Wallet
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Doing Astronomy with Python