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)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Returning Values from Bash Functions
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide