Indexing with Microsoft Word (any version) isn't easy or effective. There are a number of problems that an indexer might encounter when indexing with Word's XE fields. Over the years, I've received
a large number questions from writers and indexers looking for helpful solutions to seemingly unsolvable situations.
This article is a list of those questions, and my attempts at answering them.
If you're like the millions of people out there who have problems with Word all the time,
and then you're one of those dozens of people who found this blog about Word indexing because you're
desperately looking for a solution, please know this: I am NOT an expert on Word. I am an expert on Word indexing.
So if your question isn't about indexing, I'm not going to be much help. In fact, I'll probably ignore you if you write;
you'd be amazed how many messages I get weekly. But hey, if it turns out the index IS involved, I'll include something below. And I welcome new ideas.
Can't Find Your Problem (or Answer)?
This is a living document that should probably be a wiki: there is always something going wrong with Word's indexing features.
But I want to be helpful, and so I pushed these "few answers" to the Web right away.
If you have a question you don't see here,
please contact me at seth@maislin.com. I might have your answer, and you might contribute something this page.
If almost all of your page numbers are coming out wrong when you generate your index, then you've
stumbled across one of the stupidest side-effects of Word's indexing functionality.
It turns out that you have to hide your index to make it generate accurately. Can we say "counter-intuitive"?
Basically, you can't let the {XE} fields that you use to build the index mess up your final pagination.
The way to avoid this is to generate your index only when all hidden text
(paragraph markers, XE fields, etc.) are hidden. Then your pagination will match.
For example, if you have a paragraph that looks like this:
blahblah blah blahblah blah blahblah blahblah blah blahblah
{XE "DATA DATA DATA DATA DATA"}{XE "DATA DATA DATA DATA
DATA"}{XE "DATA DATA DATA DATA DATA"}blah blahblah blah
blahblah blahblah blah blahblah blah blahblah blah blahblah
{XE "DATA DATA DATA DATA DATA"}blahblah blah blahblah blah
blahblah blah blahblah blahblah blah blahblah blah blahblah
blah blahblah blahblah blah blahblah blah {XE "DATA DATA
DATA DATA DATA"}{XE "DATA DATA DATA DATA DATA"}blahblah blah
blahblah blahblah blah blahblah blah blahblah blah blahblah
blahblah blah blahblah blah blahblah blah blahblah blahblah
blah blahblah blah blahblah blah blahblah blahblah blah
blahblah blah blahblah blah blahblah blahblah blah blahblah
blah {XE "DATA DATA DATA DATA DATA"}blahblah blah blahblah
blahblah blah blahblah blah blahblah blah blahblah blahblah
blah
you'll notice that this paragraph is actually a lot longer than the paragraph
would be without the bracketed XE fields removed. So make sure your index
is invisible before you generate it.
For your sake, don't forget how important this is. If you generate an index
and then decide to make edits to it, you'll need to make visible your fields
again. Then, to see your edits manifest in a newly generated index, you'll
have to remember to turn them off. Many indexers get slipped up in this awkward cycle.
By the way, not all your page numbers will be wrong if you fail to turn off hidden text
before generating, especially if your documentation has many pages that aren't completely filled.
What causes the inaccurate page numbers is reflow, but if your document has very few index
entries and a lot of leeway for minor reflow, you may not even notice you're creating
pagination errors in your index. So seriously, be careful.
If your page numbers are WILDLY off, however, then you are having some other problem.
Check the settings within your {INDEX} field (the index code itself) to make
sure you're using the page numbers you want. If you're not careful, a very common mistake
that makes good writers look like complete idiots is when multipart page numbers are only half-appearing.
For example, if you have nonnumerical "4, 7, 1, 6, 3" when you should be seeing
"2.4, 2.7, 3.1, 5.6, 8.3," your multipart numbers aren't rendering properly.
Thank you so much for your most helpful website. I’ve been revising and editing a book for a client and just finished the index with wonderful MS Word. To my horror, the page numbers in the index didn’t match up with those in the text and I did suspect the codes taking up room. Your answer helped me fix it easily and quickly. ---Wendy
You generate your index, only to discover that two seemingly identical index entries are failing to combine.
For example, you're getting
Washington, George, 33
Washington, George, 37
instead of
Washington, George, 33, 37
The most likely answer is that your spacing is wrong. With Microsoft Word, you do NOT want to include any extra spaces in your entry, especially on either side of delimiters like a colon, semicolon, or quotation mark.
In other words, fields like
{XE "name"}
{XE "main entry:subentry"}
will sort separate from
{XE "name "}
{XE "main entry: subentry"}
because of those extra spaces in there. You need to get into the habit of not including them.
(This is particularly hard for writers, who think you must always have a space after the colon.)
Spaces can also appear spontaneously if you have any of Word's auto-type features turned on.
It might also be a capitalization problem. Word doesn't know how to sort uppercase and lowercase together; actually, no software really does.
So if you have entries for "Washington" and "washington," not only won't they combine, but you might get some rather funky sorting
results as well:
If you're certain it's not a spacing or capitalization problem, perhaps it's a style problem.
It's possible that your seemingly identical entries actually have formats or styles.
If one of the entries were in italics, and the other weren't, it would be obvious. But perhaps
you're using paragraph styles that do look the same, such a slightly different versions of the same font,
kerning differences, etc. Microsoft Word generally conserves style information when you
copy-and-paste text from the documentation into the {XE} fields, something many indexers do.
Different style can also appear if index entries are imported from other files, especially
those created by other programs.
In the end, the best (and perhaps only) way to make sure that your entries are identical
is to copy-and-paste one of the index entries for all of the others. That is, copy your {XE} field
and paste it in the other locations. In fact, this is how I prefer to index my Word-based documentation:
I create a single {XE} field with bogus text, like {XE "TEXTHERE"}, and then paste and overwrite for every
entry I need. Sometimes this is only way to be certain you're not introducing a hard-to-catch error, such
as an entry that has nonbreaking or en spaces instead of regular spaces, underlined underscores,
auto-capped uppercase letters, and so on.
Also, remember that a problem at the main-entry level can cause your identical subentries to combine improperly,
and vice versa. You need to make sure that every element of your entry, from the first letter of the main entry
to the last letter of the subentry (or sub-subentry) or cross reference is precisely the same, with no
extra spaces or other characters. You also need to make sure that the settings for your entries are identical,
so be sure to look at your field codes (and the spacing around them) as well.
Also, if you are using manual overrides to re-sort your entries (see how to do this below),
you need to apply these overrides consistently.
If you're certain the entries are exactly the same -- that is, you've tried the copy/paste approach I
described above -- and you're still having combination problems, then the problem might be
in a third entry that you can't see. For example, you might have two of three identical entries, with a third
entry looking the same but different. If you continue to troubleshoot the two identical entries,
you won't find a problem. Are you sure there isn't a third entry someplace? Remember that Word
ignores index entries that produce the same result in the generated index, such as two identical entries
on the same page.
After testing for everything above, I guarantee your problem is no longer related to the index data themselves.
Instead, there's something wrong with the placement of the {XE} fields, perhaps because of
some document formatting things going on, or with the document template itself. Try moving your entries around,
especially if they don't appear in "normal paragraphs." For example, if your entries are inside a table,
try moving them around within the table, such as to other columns or to positions just outside the table itself.
If they are in footnotes, take them out of the footnote and put them next to the footnote anchor. And so on.
Word is a word processor, not a publishing program; it is not uncommon that your index will get messed
up by some of the internal things that Word does. All I can suggest is to play around, doing things
that don't seem intuitive but might actually mean something to Word's internal program (like changing columns).
Thank you for your wonderful site. It's great, and I have used it a number of times. ---Jerry
Oh, but wait, you want to do it anyway? Good luck with that. I've never seen it done effectively or efficiently. However,
if you insist on trying, I would suggest either of two approaches. The easiest approach is to convert your Word document to
PDF, and then build the links in PDF. It can be done very quickly; our company offers this as an inexpensive service.
Of course, if you ever change the Word document or need to rebuild the PDF file, you have to do this all over again.
A second approach is to try to plant the raw code within the XE field, and then do some sort of postprocessing to build them.
However, with this you have to be on your own, because I've never seen this done successfully. The major hurdle is that you can't
define the anchor very well.
Your best choice is to get out of Word and build the hyperlinks using something else. Word documents can be imported rather
cleanly into Adobe FrameMaker, and a bit less cleanly into Adobe InDesign. Those programs will include hyperlinks when the document is built,
and those hyperlnks will survive output into HTML, PDF, and other formats.
On behalf of all others who have benefited from your generosity, thank you. I find it most humbling that a stranger is out there in cyberspace offering assistance as you have. ---Charles
Word doesn't care what you intend, or what words mean. Think about spell-check: if you use the word
probe instead of globe, does Word care? The same is true for your index.
If you're using the automatic indexing feature (shame on you!), you're not going to have your entries combine properly. For example, if you are trying to index "Freedman, John" and "Freedman, J." and "Freedman" as if they were the same thing, you need to be explicit in your XE field: {XE "Freedman, John"}. Word is extremely precise; in fact, if you have a space character after the word John in this example, Word won't combine them. Certainly it won't assume J and John are the same thing.
So if you want your headings to sort together, under any circumstance, then you need to type them in exactly the same way: spelling, spacing, punctuation, format, and style. After all, indexing is an editorial process, and so you need to be in charge of editorial accuracy. Word won't assume anything -- and that's a good thing, you know.
There are many reasons why your entries don't appear in the index where you want them to go, but the biggest
and most annoying reason is because Word doesn't actually know how to sort index entries! Word's sorting algorithm,
which is used not just behind-the-scenes in indexing but also as a menu-item feature, is quite rudimentary.
Basically, it's an adjusted ASCII sort, in which the uppercase and lowercase letters are considered equal,
and all nonalphabetic characters appear in ASCII order. (If you've never heard of ASCII, don't worry about it.
Just understand that ASCII sorting is only slightly more modern than punch cards.)
One kind of problem that occurs with Word's sorting is that it considers lowercase and uppercase letters
of equal value in the sort. Equal letters are sorted in order of occurrence; that is, the entry "Washington, 35" will sort
ahead of "Washington, 37" because 35 appears before 37. Consequently, if I have the initial-lowercase "washington, 36"
in my index, the result will look surprisingly painful:
Washington, 35
washington, 36
Washington, 37
Fixing this means paying closer attention to your capitalization. If necessary, you can override the default
sorting that Word applies. I'll show you how in a moment.
Another reason that something might sort in an awkward position is because you have characters or formatting
that is getting in the way. For example, the entry {XE "Washington: presidency of"} will sort before {XE "Washington:biography of"}
because of that extra little space before the word presidency, after the colon. You need to learn to not
type extra spaces in your index entries.
If you're a knowledgeable indexer, you know that subentries should be sorted by first important word.
For example, the subentry "of Delaware" should be sorted under D, not o. Word doesn't know this.
You must manually instruct word how this subentry should be sorted. Instructions on doing this is below.
Also, remember that if you manually override the sorting for a subentry that appears more than once throughout
your index, you need to manually override all of them to have them sort together.
Another result of ASCII-based sorting is that nonalphabetic characters (numbers and symbols) don't necessary
sort in the relative order that you want. For example, you might prefer that the & symbol
appear before the $ symbol. They might also appear at the top of your index before the A entries,
at the bottom of your index after the Z entries, or some combination of both. To make sure that your nonalphabetic
entries appear where you want them to appear, you will need to override what Word wants to do.
Instructions on how to do that are below.
Finally, thanks to this old-fashioned ASCII-based algorithm, Word won't care what font you're using.
In other words, the letter that appears when you press the A key will always sort as if it were
an A, even if the actual character you see on the screen is a Greek alpha. It's up to you
to override Word's behavior if you need these characters treated in some special way.
Missorted entries can happen for a lot of reason, but global missorting -- your headings aren't merged,
page numbers appear without text, heading sorting appears somewhat random -- is not that common. First, verify
that your index isn't sorting by page number; also verify that your subentries aren't appearing as entries.
The key clue is that absolutely none of your entries is sorting properly. Iain Scurrah, who shared
this problem and his solution with me in August 2007, had an index that looked something like this:
Thankfully, the cause and solution are easy once you know where to look: tracked changes.
All those archived index entries are valid entries as far as Word is concerned -- a giant and embarrassing programming bug,
in my opinion, given the nature of what tracking changes is supposed to be about! -- which means they can be affecting your index.
Tracked changes can include partial index entries, which is why you can get such weird results.
To solve the problem, Iain says you need to accept all changes before creating or updating the index.
(If you're not prepared to accept changes for some reason, then the only way to get a usable index is to
save your work in a new file, accept changes there, and then run the index there. Keep in mind that your page numbers
will likely be different than what you'd get if you accept changes in the original document.)
I was kind of abusing a TOA to make an INDEX, so I decided to replace the TA field codes with XE field codes using search and replace. The result looked just fine to me, but the entries just didn't show up in the index. Turns out it was related to "Tracked changes". After manually accepting the "Deleted: TA" changes (by right-clicking on the balloons visible in the "Final Showing Markup" mode), those I accepted started appearing in the index. After a "accept all changes" all the entries were there. ---Gert-Jan
You have very limited control over your letter heads (the large characters that set off your letter groupings). You must always use the individual letters that exist in your entries. This means you can't create an X category if you have no entries starting with X, and you can't build a combined X,Y,Z category in place of individual X, Y, and X categories. So aside from these most useful possibilities, you have a few options remaining.
You can change the format of your letter categories using the index settings, font stylings, or manual copy-and-replace. You can also remove your letter heads, or increase the amount of vertical space around the letters, using the settings.
You can also change the characters around the letter categories, or the number of repetitions of those letters, using the \h flag in your INDEX tag.
All my headings are in the wrong order! The letter heads are being created automatically. The real problem is that your entries are in the wrong order. See All of My Sorting Is Wrong!, immediately above.
I have letter heads that aren't even letters! Luis Batalha wrote me with this problem: "[W]hen I build the index using a template the places capitals separating the columns according to alphabetical order it does a strange thing when it comes to C. It puts a C and then ordinates the entries until it reaches the words China and chiricahua, before which it places a Ch. Then places a C again and carry on with the remaining entries. It isolates China and chiricahua from the rest on C." I immediately thought that this was either a dialect-related problem (especially because Luis had a .pt email address) or a ligature-related problem. In certain languages, there are letters of the alphabet beyond the 26 in English; for example, Spanish considered ll (the double-ell) a letter. I wondered if ch was being considered a letter, and thus was being used as an automatic letter head. It turns out I was right. Luis wrote back, "Once I changed the idiom (within the index tools tab) to American English it no longer treated Ch as a character (but it shouldn't do it in Portuguese anyway because it isn't)." In case someone out there has a ligature-related problem, know that ligature are single-character representations of two-character blends, created for design reasons; for example, the letters fi are often shoved more closely together, such that the dot over the i disappears into the hood of the f. If the ligatures were appearing in your index entries, it is possible (though this has yet to be proven) that the index creation algorithm will attempt to create not a "ligature head" to accommodate.
You can see the {XE} field in your documentation, but it's not appearing in your index.
If you're lucky, it's an easy fix, as described in the next paragraph. If you're unlucky, you might have
some heavy work ahead of you.
First of all, you want to make sure that you've actually generated your index since that "missing entry"
was typed. If you create, edit, or delete your index entries but don't remember to regenerate your index,
then your additions, edits, and deletions wouldn't appear in your index. Try generating your index again,
and they might just appear. (This is a common oversight with embedded indexing programs like Microsoft Word,
especially when there are several authors or other document handlers. In fact, sometimes an index is
generated and put into the production system in advance of additional changes to the index. It is of
prime importance that the index not be processed until all indexing and index evaluation is complete.)
The next-easiest problem to look for is a syntax problem. Are you using quotation marks properly?
Do you have a space after the XE letters? Did you accidentally insert an index entry into another
index entry, as with this:
{XE "main entry:{XE "inserted entry"}subentry}
There's also the possibility that your index entry includes a special character that isn't properly escaped.
For example, if you're trying to create an entry with a colon in it, you need to put a backslash in front of
that colon:
It's also possible that a necessary formatting character was escaped such that it no longer works. This
happens when non-Word documents are translated over, since most translation tools are designed to preserve
special characters as literals:
WRONG: {XE "Washington, George\:cherry tree fable"}
CORRECT: {XE "Washington, George:cherry tree fable"}
There's also the possibility that your special characters are formatted in such a way that Word
doesn't identify them as special characters. For example, if your colon is italicized, Word might
not consider it a delimiter.
Check for these kinds of syntax errors and generate your index again.
Of course, it's also possible that your index entry is appearing in the index,
but not where you expect it to appear. For example, you might have two identical index entries on the same
page; because they're on the same page, only one of them will appear in your index. It's also possible
that the entry is sorting in an unusual way because of some extra spaces or characters in your entry,
or because you're not completely familiar with how nonalphabetic characters are formatted. Also, if your
entry text has an unescaped semicolon (;) in there someplace --
a common and hard-to-see typographical error for someone who intended to type a colon (:)--
then you have overridden Word's default sort for something else. To understand better how sorting works,
and how to override it, see the FAQ items "Individual Entries Are Not Sorting Where You They Should"
and How to Override Sorting.
Another kind of "disappearance error" happens when you've used a flag in the {XE} or {INDEX} fields
to limit which kinds of entries will appear in your index. The flags most likely to be causing your problems are the
XE \f flag
and the INDEX \f flag. You
can read about other flags as well in my
MS Word Flags document.
Finally, in the worst case, it's possible that your {XE} field isn't a real {XE} field.
It might look like an {XE} field,
but Microsoft only cares that it was created properly. For example, if you've been reading this FAQ
you've probably seen lots of example fields, like this one: {XE "Washington, George:cherry tree fable"}.
But of course this isn't a real field, because it's typed manually into an HTML document. Consequently,
if I were to copy this paragraph into a Microsoft Word document (a .doc file), it wouldn't be
transformed into an index entry. It would be treated like the text that it is. Textual {XE} fields
like this one are not uncommon when files are being transferred or translated between formats and applications.
The {XE} field works only in Microsoft Word. Only with careful translation into other applications
with embedding features -- for example, Adobe FrameMaker's marker system -- will the index entries
maintain their "index entry-ness" and not become simple text.
If you can see {XE} fields in your documentation that don't appear in your newly generated index,
it's possible that you're not looking at an actual index entry. Index entries have to be inserted using
Word's index-entry-creation dialog boxes (see your Help system), or copied from other valid entries.
Trying to type {XE ... } will not give you what you need.
So let's suppose you have textual fields that you need to convert to index entries. What you need now
is a way of creating those fields quickly, and no such tool really exists. However, at least you
can use the search feature to help you out. Start by searching for the uppercase XE to find your entries.
(If your textual entries aren't formatted with hidden text, I recommend hiding hidden characters
while you do this search to avoid accidentally finding your real index entries.)
Now, every time that you find a textual XE field, highlight the index entry text and create a real
entry from it, using Word's index entry creation features. (If you're clever, you can create a toolbar
button to create an index entry, making this job a bit faster.)
If you're feeling particular industrious, I recommend building a regular expression that will find complete XE fields in your text,
from opening brace to closing brace, and call out the index data as a subexpression. You can then replace everything you
find (the whole field) with a uniquely formatted version of just the subexpression (the index text). Choose a format
that is not going to appear in your index, like a new named style or a strange color. Now, you can search for the formatted text one
item at a time, sped along using the unique format, and create index entries from them.
Afterwards, go back and delete your formatted text.
If those solutions seem a bit obtuse, it's because they are. If you have index entries that aren't
properly embedded, you don't really have index entries. The approaches I've loosely described in the last
two paragraphs are attempts and shortcutting the "indexing from scratch" you have to do.
(By the way, I occasionally offer my services as an automoton when it comes to global index data
conversion in Microsoft Word. If you need my help -- that is, if you want me to fix your
index or index data -- write me, and we'll talk.)
After all that, there are always problems that have nothing to do with the index data themselves, but
some other kind of problem that's happening at a higher level within the Word processing. For those
kinds of problems, you should probably consult a mailing list of technical writers, who are much
more familiar with the global or template-level properties of Word documents than I.
I just want to say -- I am forever indebted to you for providing the only help I could locate on troubleshooting indexing! ---Teresa
It is absolutely no surprise that your page ranges are having problems. Microsoft Word's functionality
for page ranges is abysmal. The only good thing I can say about it is that is exists! (There are other
applications with embedded indexing functionality that don't allow for the existence of ranges, like
the add-in for Quark. But wow, who's writing a big index using Quark?)
For your ranges to be working, three things have to happen simultaneously. First, your {XE} syntax
has to be correct. Make sure you're using quotation marks when appropriate; in fact, it's a good idea to
use them all the time by default. (If you don't know the syntax, read about the
\r flag at my syntax page.)
Second, you have to have a valid bookmark name as the argument to the \r flag. Third, you have
to have am existing, functional bookmark with a name that matches your argument.
Stay away from naming your bookmarks with special characters, or anything else that might interfere with the indexing process.
That means you shouldn't be using colons, semicolons, backslashes, or quotation marks -- but you shouldn't
be naming things with those characters anywhere, anyway.
The limitations of your bookmarks are the same limitations in your page ranges. For example, you cannot
create a range that goes across multiple documents (i.e., a range that starts on a page in one document but
ends on a page in another document). Also, document editing can invalidate your existing bookmarks; it's possible,
for example, for you to cut the endpoint of a bookmark and then paste it before the starting point, or into another file.
Bookmarks are a really ugly feature of Word, so when indexing, it's important that you learn when they don't work.
Bookmarks that don't scan across multiple pages may (or may not) appear as ranges in your final index.
For example, instead of getting "Washington, George, 101-101," which you wouldn't want anyway, you might
see "Washington, George, 101" and think your bookmark is broken. If you're working with very small sections
of text, it's my recommendation that you don't create ranges anyway; a range of two pages isn't particularly helpful
to the reader. (This is a theoretical point that I would be happy to argue, but not here.) In other words,
if you are indexing a passage of just a couple paragraphs at most, don't use a bookmark; the likelihood
that those paragraphs will run across two pages don't make up for either the risk of error, let alone the added
effort required to build the range in the first place.
You might have some trouble if you are trying to create page ranges that overlap with other page ranges in your index,
or have internal single-page entries. For example, if you're creating an entry like "Washington, George, 101-109, 102-107,"
there could be trouble. (Actually, Word probably won't have any idea that you're making this mistake -- which is worse!)
Finally, if you are attempting to carry your ranges from or into other software applications or formats,
such as Adobe FrameMaker or Adobe PDF or even simple HTML, I guarantee your ranges will vanish. The bookmark paradigm simply
does not exist in any other program to my knowledge. (What other proof of its terrible-ness do you need?
Why does Microsoft insist on keeping this feature alive? Have they never heard of HTML anchors?)
Consequently, if you are producing documentation in more than one print or print-like format, accept that
you'll never be able to work with page ranges without a lot of extra editorial work.
Automatically? No. Word is doing what you tell it to do. If you created lots of {XE} fields next to each other, the only thing that Word will do is prevent duplicates. So while you won't get "15, 15, 15, 16, 16, 17, 17," you will definitely get "15, 16, 17." If you prefer "15-17," then you need to index using ranges.
There are two solutions for you, and you won't like either. Solution 1: Undo your indexing approach. For each instance where you have adjacent page numbers, create a bookmark for the range, use that bookmark to create a range-type entry in your index, and then delete your individual markers. Solution 2: Edit your resulting index manually, by deleting your strings of page numbers and typing in what you prefer to see. But please don't do this! Not only can you erase all of your hard work if you (a) regenerate the index or (b) edit the text so that you have to regenerate the index -- remember that rebuilding your index will erase all of your manual labors -- but it's unbelievably easy to generate typos when you're typing page numbers.
By the way, long lists of individual page numbers is what you'll get is you're using the Automark feature, and as I say elsewhere in this document, that's not indexing.
(Please note that strings of page numbers are not necessarily wrong (though usually they are). It is perfectly possible to have an indexable item appearing independently across multiple pages, without that item being discussed in a narrative, range-like way. For example, this document itself mentions subheadings over and over again, but isn't about subheadings from start to finish.)
No surprise there! One of the places where Word tends to fall down is with cross references. That's because
cross references are treated as ordinary text; they don't actually link to anything. Cross references within
the {XE} fields are no different than my typing "Washington, George. See also U.S. presidents" right here.
It's just ordinary text. For this reason, all of your formatting (and most of your positioning instruction)
will have to be managed editorially, like the rest of your documentation.
First of all, the italicizing of the words See and See also, as the Chicago Manual
recommends (and don't get me started on why I dislike Chicago-set standards, especially within
embedded indexing) has to be handled manually. You can't use named styles, which means you must actually
highlight the text you want italicized, and then italicize it. If you're using the dialog boxes to create
your entries, italics might very well be the default, but remember that the result isn't using styles.
Consequently, if you end up doing anything to your document globally in an effort to change your italicized
text into something else (e.g., some fonts have special italics versions that look better), too bad. Your index
won't cooperate, especially if you're porting the index into another document.
If you need to create a special kind of cross reference, such as a See also specific, you will need to
italicize within the document window; you can't do any text-level formatting within the dialog box.
The positions of your cross reference are not negotiable. If you use the standard syntax of the \t flag
(see XE \t flag,
your cross reference will always appear after the entry itself. What the \t flag is really doing
is allowing you to type in whatever you want as if it were a page number. In fact, this will allow you to
create See references next to page numbers, which is a big no-no according to every indexing
guideline you'll ever see.
So what happens when you want your See also reference to appear among your subentries?
Well, first of all you'll need to misuse the \t flag syntax. Second, you'll need to override
Word desire to sort the word See as a real word and not as part of a cross reference.
The result is something like this, in which the cross reference will appear below all the alphabetic subentries:
{XE "Washington, George:See also U.S. presidents" \t ""}
Notice that I still have an argument for the \t flag, even though it's an empty set. I'm not sure this
is strictly necessary, but I think it's good for the sake of consistency. Also note that the example
as it appears here does not use italics. You could, and you probably should if you're a fan of Chicago;
I didn't here for the sake of readability.
The next problem you'll have is that Word doesn't know that when you have more than one cross reference,
they need to be combined. Remember, Word is looking at these things as if they're text, not actual and meaningful
elements of indexing. So if you have a series of cross reference targets, you'll need to type them into
a single index entry, using escaped colons:
{XE "Washington, George:See also U.S. presidents\; Washington, Martha" \t ""}
There is one good thing about the syntax of cross references when you're embedded your index data, but it's
not something unique to Word: You can put your cross references anywhere in the documentation. Although it's
usually a good editorial idea to keep your cross references near the text of the cross-reference target,
it's a good production idea to keep all of your cross references in one place, such as within
the preface. Having all your cross references in one place is also useful for language control.
If your entire index vanished without a trace, consider first that your problem has nothing to do with indexing.
(This is sort of like wondering why your computer doesn't work, when in fact the monitor is unplugged.)
Are you looking at the right file? Did you delete the index, either by accident or with the intention of starting over?
Did you insert more text or other content after the index, so that your index exists but is no longer at the
end of the document where you expected it?
Are you sure you ever had an index, and that you're not remembering a different file or circumstance?
However, there are two index-related things you could have done. First, look to see if there's an {INDEX} field code
where the index used to be. If so, then you do have an index, but it's not being displayed. You can toggle (switch on/off)
between seeing the {INDEX} code and the index itself by right-clicking on what you see and selecting the "Toggle field codes" option.
By allowing you to see the {INDEX} code, in theory the application is allowing you to manually make some syntax changes
to the index without having to go to the menus. (To learn about the {INDEX} code, see my
word flags document.
On the other hand, if you can't see the {INDEX} code, it's possible that you're hiding all your codes. Make your hidden text
reappear by clicking on the paragraph button, or selecting View > Show All. This is what you'd have to do to make your {XE} fields visible as well.
If all of your entries are suddenly invisible, it's probable that you simply hid all your formatting codes. Click on the toolbar button
with the paragraph symbol on, or select View > Show All from your menu. That should make them reappear.
If making your codes visible didn't make your index entries appear, then you did something non-index-related that made them vanished.
The most likely culprit is that you saved your document in a text-only format, or some other format that doesn't have index tags, causing them to be deleted.
Alternatively, you might have cut-and-pasted them all away globally, on purpose or by mistake. After that, who knows?
Perhaps you're in the wrong document, or maybe you only thought you had index entries, when in fact you never did.
If you inserted continued lines into your index, you did so manually, after you had a generated, editable index. However, manual changes are just that: manual.
If you regenerated your index at any time after you made those manual changes, all of your manual changes disappeared. If you need to apply edits to the
index manually, you MUST make sure not to implement these changes until the index is finished, never to be regenerated again. This applies not just
to additions like continued lines, but also to spelling corrections, punctuation changes, and formatting changes.
There are two ways to make your XE invisible. The most obvious, and the one you probably
tried before coming to this websites, is to show/hide all hidden characters. It's the button
in the ribbon with a paragraph symbol in it, or an option in the View menu. If you are
showing your hidden characters, you will see not only the XE fields, but also the whitespace:
paragraph, line break, and page break symbols; spaces and tabs; and so on. However, if all of
the whitespace symbols are not visible and you can still see the XE fields, then
you need to do something else.
Microsoft Word has a useful feature to make all hidden-text codes visible, for those times
when you want to be able to print them. Or maybe you want to write your index without having
all of your hidden text visible and cluttering up the screen. To make them visible,
go into Page Setup (available from the File menu) and look for something
that says "print display codes" or "print hidden text" or something like that. To make them
invisible, uncheck that same box.
No, that ___ isn't a substitute for a curse word. :-) It's a fill-in-the-blank for whatever your own specific needs may be.
Every now and then, there's nothing you want to do more than globally delete a bunch of entries. I'm going to talk about this
in two ways. First, I'll talk about how you can remove a selection of index entries. Then, I'll talk about how you can
delete all of your index entries -- that is, to delete the index data entirely, so you can start over.
How to delete a selection of entries. For example, suppose you have a common main entry for "publicity," when you decide that you're better off with a cross reference
like "publicity. See marketing." In addition to creating this cross reference, you need to remove all of your original publicity entries.
Although you can search for marker text, you can't search for whole markers. In other words, you can search for the word "publicity" when it's used within index markers
(look for hidden text), but you can't search for a whole marker like {XE "publicity"} or {XE "publicity:methods for"}. For this reason you can search globally and delete.
The easiest approach to deleting all publicity entries is the manual approach: generate your index, then delete everything that starts with the word publicity.
Unfortunately, manual edits will be undone as soon as you generate the index again; you'll have to remember that you want to make these manual changes every time you
create a new version of the index. To help you remember to make these manual changes, I recommend changing the format and/or language for the word publicity to make sure
it jumps out at you. Search for XE "publicity, the unique text for all publicity entries, and replace it with boldface, all caps, and a shocking color like red.
I also recommend that you change the word publicity with something that will sort at the very beginning of your index, such as aaa DELETE ME. Now, when you generate
your index, you'll see some red, boldface, all-caps reminder at the top of your index file. Hopefully this will be enough for you to remember deleting your entries.
Another approach, and by far the one I prefer, is to replace the marker syntax with something that Word can't interpret. Instead of using the letters XE in your marker, use something
like DELETE_ME. In other words, globally change XE "publicity with DELETE_ME "publicity. Since markers are hidden text, your DELETE_ME markers will remain hidden
from publications; further, they'll fail to become index entries since Word won't interpret them as XE markers. The biggest advantage to this method is that it works globally, and you
only have to make these changes once. Another advantage is that you aren't actually deleting the entry, just rewriting it; if for any reason you need to reconstruct entries, you can
always change DELETE_ME to XE. (This is a kludgy way of creating conditional text, but it might be just what you need.) The disadvantage is that you're not actually deleting anything,
potentially cluttering your documentation.
As a side note, whenever you remove an entry from your index, remember that you have to delete any cross references that target those now-removed entries. For example, if you replace
your publicity entries with "publicity. See marketing," you'll need to rewrite or delete entries like "public relations. See also publicity."
How to delete all of your XE fields. Search for all fields by using ^d in the search-replace box.
If the XE index fields are the only fields that you use in the entire document, then you can safely delete them all using search-replace, and you're finished. Woo-hoo!
But if you have other fields, then you need to figure out where they are so you don't delete them too, by mistake.
One approach is to check the box to select all matched items, when you search for ^d. This will highlight every field in your document, all at once.
Then make them all a certain color that you don't use, like orange. Now, without unhighlighting them all,
copy/paste all of your orange fields into another document, with hidden text visible so you can see what you're doing. You'll get a long paragraph or list of every field.
Now, using this fields-only document as a reference, scan your fields to see what kinds of fields you don't want to remove.
Go back into your original document, search individually or in groups for the fields you want to keep, and manually change their colors back to normal,
so they're no longer orange. When you've un-colored all of your non-XE fields, search-and-delete all orange fields from your document.
Note that the value of copying your fields into another document is that it allows you to see them quickly for review.
If you're able to browse your documents manually to find the non-XE fields, or if you know exactly what non-XE fields you have, then you can probably avoid the second document.
Alternative: I recently learned that there's a macro you can use to remove all index entries too. I don't program many
macros, so I can't attest to the success of this one, but it comes well-recommended.
See http://articles.techrepublic.com.com/5100-22_11-6170792.html. And let me know what you thought. (Thanks for Michael G. for this one.)
If you are trying to create an index heading that includes a colon (:), quotation mark (" or '), semicolon (;) of backslash (\), it won't work unless you tell Word that you're not using this symbol as part of the index tag syntax. After all, colons, quotes, semicolons, and backslashes are command syntax. To include these characters in your index headings, put a backslash in front of them. For example, this is a legitimate XE field:
{XE "searching using \"with\:public\" syntax"}
and will get you an index entry like
searching using "with:public" syntax, 100
If you are having trouble with other characters, it is possible that you have a font or localization issue. Remember that XE fields sometimes take on the styles and fonts of the paragraphs around them, and sometimes they don't. I've never figured this out. Just override what's in the XE field with what you need, and see if that solves the problem. Also, certain special characters like en, em, and nonbreaking spaces may or may not translate properly as you go through the indexing process. If you're having real trouble, you might consider using a nickname like NONBREAKSPACE and then manually changing them as the last step after you've generated the index.
Another possible problem is that the quotation marks you're using for the XE field aren't what you think they are, or they're missing. I believe you can use both double and single quotes for enclosing your data, but it's important that the quotes match. Also, be careful that your quotation marks didn't become curly quotes by mistake; if you're creating or editing your XE fields manually (not using the dialog), which I recommend, you need to turn off the autocorrect features for smart quotes. There are now two settings for smart quotes, and you have to change both. (And while you're in there, watch out for the automatic insertion of spaces.)
If you've created an index where almost all of your main entries start with lowercase letters, but you want uppercase letters instead, this is easy to fix.
If you have an index with all uppercase entries but want them to start with lowercase by default, this is much harder. In both cases, however,
there are only two reasons you need to do this. First, either you created the index using one style, only to discover that a different style is preferred --
for example, you capitalized everything but later learned that using lowercase is the preferred way of indexing -- or else you used Word's
automatic indexing tool to create your entries. The first scenario can be avoided by using lowercase by default, from now on, always; using uppercase
is a bad stylistic choice in all circumstances, despite some industry standards. Additionally, it's much easier to start with lowercase and
change to uppercase than to go in the other direction (as we'll see). So always start your entries with lowercase letters by default. Always.
But with the second scenario, where you are allowing Microsoft Word to create your entries, shame on you. That's not an index. Word's automatic
tagging functionality is not indexing, but rather a concordance builder.
That said, if you really want all uppercase letters (against my advice) and yet someone have an index that uses lowercase letters, it's an easy fix.
Start by making your {XE} tags visible, and then use case-sensitive search to find any occurrence of XE "a.
This will find entries in which the first character is a lowercase a. You can then replace this with the uppercase version, XE "A.
(NOTE: If you are using autocorrect for quotation marks, turn that feature off before you perform this task. You don't mismatched quotes in your index entries.)
Do this 26 times, once for each letter of the alphabet.
Alternatively, more current versions of Word have capitalization as a stylistic choice. You could use this style to replace all occurrences of
the expression XE "^$ with itself, but capitalized. Be careful with this approach because you will be adding styles, not information; if your index
is ever stripped of font information, you will lose your capitalization. Also, but adding styles to the XE characters, you may cause
trouble with other algorithms in your production process.
Why is it so hard to go in the other direction, from uppercase to lowercase? Because in reality you don't to remove the uppercase
character from all of your entries. Some of your entries are supposed to be capitalized, like names of people and places, and most acronyms.
If you globally capitalization, you will be creating errors in your index. So while the method is the exact reverse of the procedure
described above (replace XE "A with XE "a), you must then carefully go through your index to find all mistakes that these
find-replace activities have caused.
Thank you very much, I've been trying to get this done for months. It's great to have someone like you to explain things to someone like me. ---Richard
The answer to this question is quite simple. You can use the \f flags in your XE and INDEX markers
to build relationships between your markers and the indexes that use them. For example, an index entry
{XE "online directories" \f "subject"} will be considered in an index marked as
{INDEX \f "subject"} but not {INDEX \f "name"} because the values for the \f fields need to match.
Additionally, if there is no \f field in the {INDEX} marker, all index entries,
regardless of their \f values, will be included. I've written about all the {XE} and {INDEX}
flags in my Word flags page.
Before I continue, let me explain this AGAIN, and in the simplest terms possible, how to do this. You'd be amazed how many
people are still writing me saying, "but I don't get it." :-)
An index is comprised of two pieces: a bunch of {XE} fields, and an {INDEX} field. If you insert an index using the menus and then right-click on the results, select the Toggle Fields option so you can turn the calculated index into the {INDEX} code that’s underneath. The \f tags in your XE and INDEX fields must match, in order for those XE tags to be represented in that INDEX. So if you want a name index, add \f "name" to all of your XE fields, and add \f "name" to your INDEX field, too. Then for your second index, you can create a whole new bunch of XE fields with a different \f value, and generate a new {INDEX} with the same \f value.
The result will look something like this:
text text text {XE "heading1" \f "name"} text text
text {XE "heading2" \f "name"} text text text text
text text text {XE "heading3" \f "subject"} text text
text text text {XE "heading4" \f "subject"} text text
...
NAME INDEX
{INDEX \f "name"}
SUBJECT INDEX
{INDEX \f "subject"}
where the indexes could look like these:
NAME INDEX
heading1, 987
heading2, 987
SUBJECT INDEX
heading3, 987
heading4, 987
Now, working with multiple indexes can be tedious, but the job is made harder by the fact that there's no good way
to input \f flags in your entries. After all, there's no way to use this flag in the dialog boxes.
A shortcut I can recommend is to use a bottom-level entry to contain your flag value. For example, instead of creating entries like
{XE "management strategies"} and {XE "management strategies:swift punishment"}, append a sub(-sub)entry to
every entry: {XE "management strategies:mysubject"} and {XE "management strategies:swift punishment:mysubject"}.
Then, as soon as you're finished indexing that chapter or section, globally replace all :mysubject" instances
with " \f "mysubject". This will create the entries you want:
{XE "management strategies" \f "mysubject"} and {XE "management strategies:swift punishment" \f "mysubject"}.
Of course, a real shortcut wouldn't use a phrase like "mysubject" when ":S" will do. After all, how often does your document
contain the characters :S"?
One note about multiple indexes. If you are using multiple specified indexes -- like a \f "subject" and \f "name" index,
as opposed to an unspecific index with no \f flag -- you will need to insert your index entries more than once.
{XE} fields can't have more than one \f flag in them. That means you're going to have to double up if an entry belongs
in multiple indexes: {XE "management strategies" \f "subject1"} and {XE "management strategies" \f "subject2"}.
Now I was recently asked an interesting question. Basically, if the entries for two different indexes are formatted differently -- for example,
if the place names are single-underlined and the personal names are double-underlined, in advance of indexing -- is there an easy way
to create the entries from these notes? In other words, can I automatically generate index entries for the single- and double-underlined items,
to create two different indexes?
I think so. As we've seen, we want to use the \f place and \f personal flags for place name and personal name indexes, for example.
Let's start with place names, which are single-underlined. To get the index entries for your single-underlined items into an entry with the appropriate \f designator,
search for single-underlined items; as each is found, use the menu options to create an index entry for the highlighted text. Then, before you index
the double-underlined items, replace the characters XE " with XE \f place ". This will identify every entry you have in your index
as a place-name item. Then, do the exact same thing for the personal names, but using XE \f place " as your replacement text.
If you are trying to accomplish this with tags already in your index -- for example, you might have XE fields for a subject index, while you're trying to
also create entries for place and personal names -- then you need to "hide" them from the search-replace process. Just change XE " to XEHIDE " throughout,
before you do any replacing. Then, when you're done, change back all XEHIDE mentions to XE.
Here's another big warning. Whatever term you use as the argument to \f, like \f "name" and \f "subject", Word looks at only the first letter. That means using the arguments sites and species won't get you want you want at all, because Word only notices the initial s in both words, and they match. Remeber my example "place" and "personal" above? It won't work, because both of those words start with p. I still recommend using whole words for human readability and ease of find/replace, but please make sure they start with different characters (letters or numbers). Change "place" to "location" for this example, and you'll be just fine.
Genius. This seems to have worked. And just to check that it's only first letter that counts, I changed the name of the index to "something", re-indexed and again I got single index. This seems to an undocumented "feature" of Word 2003. You've saved me an awful lot of work and heartache. Thanks again. ---Dave
If you're building multiple indexes using the \f flags, but you're only getting one index, then you have
one of two problems.
First, remember that you have to have two {INDEX} tags if you want two indexes. (You'd be surprised how many
people think both indexes will happen by themselves.) Simply insert a new index where you want the second one to go.
Then, make sure that you're using \f flags in the {INDEX} tags that match the ones you're using in your
{XE} fields. I've written about all the {XE} and {INDEX}
flags in my Word flags page.
The other possible problem is that you think the \f flags are actually a powerful tool. They're not. Only the first
character of your values matters. So if you're creating name and subject indexes, using the values
name index and a subject, it will work because Word looks at only the first characters, n and s.
But if you're using values like general and geography, or commands and controls, or
answers and affiliations, Word doesn't know the difference because those value pairs start with the same letter.
it's an easy fix: search and replace all occurrences of \f "____" (or whatever precise syntax you're using) with
a value that starts with a different first letter.
If you do this often and need flexibility, I recommend using codes that start with numbers and end with descriptive words.
Instead of using "names" and "subjects" as codes, use "1_names" and "2_subjects". This will make it easier for you to
add indexes without worrying about words, finding all the codes of a specific index and changing them, or semantically changing
the intention of "second" index, for internal note-taking purposes.
This question was beyond me until someone pointed me to a valuable resource at the
Microsoft MVP site.
The simple answer is that you need to insert a section break at the end of the document, and then change the endnote setting
to "end of section" instead of "end of document." Then your index can come after.
Thanks to Gary Williamson for pointing me to this answer.
If you've browsed my other Word index page about Word's formatting codes, then you know that some of Word's
more-useful functionality requires you to manipulate the options for the {INDEX} tag. But perhaps you're wondering,
where is that darn tag?
To access the {INDEX} field, you need to insert an index first. Then, once the index is visible, right-click on the index and select the Toggle Field Codes option.
This will make the index appear as the {INDEX} field, with its options.
As you can tell from the language of the question, I'm not fond of the automatic indexing features of
Microsoft Word. In truth, my issue isn't that the feature exists. I have a problem with this feature
being called "autoindex," as if computer-generated indexes were actually any good. They aren't.
Computer-generated or automatic indexes STINK. I've had this discussion many times with many people,
indexes and non-indexers alike, and we are all 100% in agreement. You can't build an index using computer logic.
Some people seem to think that in very limited circumstances you can come close; they're wrong.
Other people believe that if an index is "not too bad," that might be acceptable; again, they're wrong.
The problems endemic to computer-generated indexes are not only serious, but they're nearly
impossible to correct editorially -- unless you're willing to start over, that is. Additionally,
the most serious problems facing automatically created indexes are invisible:
important ideas that weren't indexed at all, trivial ideas that shouldn't be in the index but are,
miscategorized ideas, badly combined ideas, and so on. Automatic indexes can look good,
but their failures are much too serious to be ignored. If you know anything about indexing,
or if you care about what your readers think, you should know that an automated index is actually
worse than having no index at all. Readers will trust a bad index and get burned; having no
index will at least give readers a fighting chance to find that information some other way,
such as with the table of contents, by browsing, or simply from memory.
So there's my question: What good is the automatic indexing feature of Word?
The answer lies in understanding what this feature actually accomplishes: it finds every occurrence
of something you want, and marks it with an index entry. This is NOT indexing, but in some situations
you might still want to do this. (Use at your own risk.)
I hope you read my previous entry on automatic creation of indexing entries. If you didn't,
please scroll up (or click here) right now, before continuing.
If you're going to use the auto-marking feature after all, for whatever reason (including reasons
that aren't about indexing), you may quickly discover that Word doesn't pay very good attention
to what you ask it to mark. Styles, formatting, capitalization, hyphenation, and even quotation marks
seem to escape the notice of this already terrible feature. For example, if you need to search
for all instances of a lowercase word like president, you may not find all occurrences
of the uppercase word President, even when it is capitalized as the first word in a
sentence. Additionally, auto-mark tries to be helpful my maintaining the case of what you mark,
which means you'll get some entries with lowercase president and some entries with uppercase
President, and these won't combine nicely in your generated index. The only circumstance
in which these things don't matter (and auto-marking actually makes a tiny bit of sense) is
when you're creating a name index. However, to build a real name index you'd have to auto-mark
every single name that appears in the whole book -- and even then, it won't work unless each name
appears in a unique way throughout the book.
So how do you get around the picky nature of auto-marking? Simple. You need to globally search-and-replace either (1) what you want to auto-mark or
(2) what you want auto-mark to ignore, before you attempt to use the auto-mark feature.
For example, suppose you want to create an {XE} field for every italicized occurrence
of the word missing, but you don't want to create an {XE} for the word when it appears
in roman typeface (i.e., not italics). Before you run auto-mark, find every italicized occurrence of
missing and replace it with something unique like ITALmissing. Then run auto-mark,
looking for the invented term ITALmissing. You'll get fields that look like {XE "ITALmissing"}.
As a last step, globally replace all occurrences of ITALmissing with the original,
italicized missing. Now your text is back to the way it was, and your index entries match.
Another problem is with quotation marks. Auto-mark doesn't work with quotation marks, probably because
the {XE} fields themselves use quotation marks. So, globally replace all quotation marks with
terms like QUOTEHERE or DOUBLEQUOTEHERE before using auto-mark. Then, if you were hoping to create
index entries for things like "Hogan's Heroes" (which has an apostrophe that would otherwise break
the feature), you can auto-mark for "HoganAPOSTROPHE_HEREs Heroes" to get your {XE} fields.
However, you need to be extra careful with quotation marks! You must not globally
replace your QUOTEHERE marks with quotes. That's because a quotation mark in an {XE} field
will mess things up. Instead, you're going to need to replace the QUOTEHEREs in your index fields
differently than the QUOTEHEREs elsewhere, which means you require two final steps, not one.
First, search for QUOTEHERE and APOSTROPHE_HERE as hidden text; since the {XE} fields
are hidden, this search will find only terms in index entries. Replace these occurrences with
not with a quote mark, but a quote preceded by a backslash: \" or \'. That
backslash tells Word that the symbols that follows -- the quotation mark or apostrophe -- should
be treated literally, and not as part of the {XE} field syntax. Then, as a second step,
you can globally replace any remaining QUOTEHERE-like terms with your quotes. One last warning
about quotation marks is that depending on your settings, curly quotes might not search-and-replace
as cleanly as you'd expect. While a non-curly quotation mark will find both opening and closing curly
quotation marks when you're searching, replacing them may not auto-correct as you'd want them too
for every occurrence.
An alternative approach to those two final steps for putting your quotation marks back is the following.
First, hide your index tags by making all hidden text invisible. (You do this in the same way
you make your paragraph symbols disappear.) Second, replace all QUOTEHERE-like terms to quotation marks.
Third, make your hidden text visible again. Fourth and finally, replace all QUOTEHERE-like terms
with the backslashed versions, as described above.
The quotation mark is a special character because it's used in the index marker. The other
special characters that require a backslash are the colon, the semicolon, and the backslash itself.
If you needed to auto-mark terms that have a backslash in them, your index entries will need two
backslashes to represent just one. (If this seems really weird to you, that's only because you've
never been a programmer. I guarantee that the programmers who are reading this
paragraph are nodding to themselves.)
You can use this same basic technique for anything you want, as long as you can find a way to
isolate and group the terms that you want to index from the terms you don't. If you want to find
all occurrences of president and President, but you don't want your {XE}
fields to use the capital P, you can replace all capital-P Presidents with
something like CAPPresident and then auto-mark them. Then replace all hidden-text CAPPresident terms
with the lowercase-P version, and all non-hidden-text CAPPresident terms with the uppercase-P version.
Then automark the lowercase-P presidents as you would normally.
You might think that it would be easier to search-and-replace your index after you've created
these two types -- for example, you might create {XE "President"} and {XE "president"}
tags first, and then try to replace "P with "p globally -- but you run the risk
of changing things you didn't want to change. After all, "P can appear in your text, too.
One last option, which is quite fast, is to keep all those QUOTEHERE-like terms in your index tags
forever, but simply remove or replace them from the final generated index. Although I don't recommend
this, this approach makes a lot of sense if you're going to be converting your Word documents into
other tools. Just as the quotation mark is one of the few special characters in the
{XE} field syntax of Word, remember that there are special characters in the other tools as well.
If your index entries are going to survive all of those conversions, you might need to pre-treat
the characters that are considered special by those other applications. For example, Adobe FrameMaker
index markers can also have bracketed content; square brackets and angle brackets in your Word document
might fail you once you convert into FrameMaker.
Automatically? No, not that I know of. Word calculates your page numbers automatically, and simply put, there is no page
number that looks like 135n12.
If you insist on doing this using Word, you have two ways to approach the problem. Neither is perfect or fun.
First, you could try to put each footnote or endnote on its own page within a separate section, and then renumber
the pages to match what you want them to be. This is really ugly, though, because you'd have to know all your
page numbers in advance -- which defeats the only good thing Word does for you (calculate page numbers automatically).
I strongly recommend against this approach.
Another approach is to use boldface and/or italics for the page number itself. If you're using Word's dialog boxes,
there are checkboxes. If you're using the {XE} fields manually, you need to insert the \b or \i flags in there to
add boldface or italics to the page number. (For more details see https://taxonomist.tripod.com/indexing/wordflags.html#XE-bi).
If you are using boldface for the references to your notes, for example, then you can easily find them in your generated index
to add the n character, using search and replace. However, if you also need to add the number of the note itself,
then you'll still have to go back and look. By using bold, italics, or both, at least you will know at a glance which
entries you need to look at a second time.
Yet another possibility would involve typing the note number into the index entry itself, sort of like this:
{XE "main entry:subentry:n12"}
If this field were on page 35, the result would look like this:
main entry
subentry
n12, 35
Through some fancy manipulation, you could then change n12, 35 into 35n12 and run up the page number
to the level above. However, please note that this approach requires two incredible feats. First, you'll have to get
the note number right. If you're still adding, deleting, or reordering notes this is will be hard. Second, if you have
other page numbers at the level above the note, you'll have to manually sort those noted page numbers:
main entry, 156, 158
subentry, 180-184, 35n12 <-- wrong order
Then again, at least you're one small step closer to doing it automatically instead of manually.
Finally, in the Q&A immediately following this, I provide some advice on how to create an index of references that use other sets of numbers
that are different from page numbers, in the many-to-many subsection. That method would work if you were interested in indexing
the notes by note number, leaving the page number completely out of it. That is, instead of trying to get "135n12," you were
satisfied with just "12" (where 12 is the note number), you could use the method below. To expand on that method,
however, I would recommend not using "12" but rather something like "1000012" for the 12th note in chapter 1, "2000012" for the 12th note in
Chapter 2, and so on. Once that index is generated, you can use the extra 10000 and 20000 as easy-to-find pointers to what chapter the
notes appeared in. That would speed up the process of manually entering page numbers, especially if you're using end notes that all
appear on the same few pages.
Lastly, let me say that if all of the answers to this section are driving you bonkers, I'm sorry. Like I said, there's no way to do this.
The best I can help you do is create a process that, despite its complications, gets you a little closer to working less manually.
In my experience, I have found that trying to read the index entries as I work is both necessary and challenging. The best
productivity hint I can offer you is an easy one: make all of your index tags the same color. I recommend a dark color, like purple,
and a color that is easily selectable from among the choices provided in your Font dialog. (If you have live links in your text,
don't use blue or purple, which would be easily mistaken for hyperlinks.) You can then take advantage of this coloring to see
the tags, see their contents, and even search only among tag text.
In the indexing work that I do, I rarely have fields other than XE fields, so changing tags to a single color is easy.
Using the Find/Replace dialog box, search for ^d, put ^& in the replace field, and select a color using the Font options
for the replace text. This will change all your fields to the color of your choice. Now if you have fields galore, you'll
need to go through the fields one at a time; or, if your XE fields far outnumber any other fields, replace all and then go back to
undo the coloring for your other fields. Finally, note that coloring most other fields makes no difference anyway, since they contain
no rendered text.
A far better approach to using coloring is when you are creating the index from scratch. Create a single index entry, color it manually,
and then copy-and-paste that tag every time you want to create a new one. I dislike the input dialog anyway; copying an old tag and then manually
editing its contents is my normal mode of indexing. Color helps for creating entries, since you need to keep track of what you're doing;
it's far less useful once all the entries already exist, anyway.
One last note: if you use purple XE fields, you'll get a purple index. Thankfully this is easily correctible, either by removing all
color before generating (which is a shame), manually changing the index after generation (my preference), using some kind of styles
(don't know how this would work), or starting with a black-looking color to begin with. Depending on where your index is going to be
rendered (printed or posted online, for example), final color may be important, though usually it's not until the very end.
A common need for indexers is to build cross-references for terms that have initialisms (including acronyms).
For example, if you had "File Transfer Protocol (FTP)" in your index, you'd also want "FTP. See File Transfer Protocol."
(Note that this guideline works even when you put the page numbers at FTP and the cross reference under File.)
Since cross-references can appear anywhere within a document -- after all, they have no page numbers -- here's your productivity tip:
Build them all at once.
Build and generate your entire index except for the cross-references. Then using your generated index as a starting place,
collect all lines that have parentheses in them. You can do this manually (the easy way) or with regular expressions (the effective way).
Once they've been collected, you can manipulate them all at once, reversing the text to create the text of your cross references.
Then, line by line, you can drop them into your documentation wherever you want, like in a preface or bibliography, where they
won't get in the way.
Another approach is to grab the XE fields themselves by searching for tags containing parentheses. (Even better, if you made
sure that all of your XE fields were in a different color (see Using colors for XE fields above),
you can search for purple parentheses. This is another way to grab them for conversion into cross-references.
For one-to-one lists.
It's not uncommon for people to use Word's indexing feature to create something that's not really
an index. For example, many authors attempt to use the those {XE} fields as a way of creating things like
tables of figures. Using [XE} fields is most certainly the wrong way to do this -- by design, that is --
but a lot of Word's features are pretty ugly. So if you're familiar with indexing, why not?
Also, in some cases you want to create a list of items where what appears in the list doesn't precisely
match what appears in the documentation. For example, if you wanted a list of figures where the figure
number appears last, what you want to do is create fields like {XE "TITLE OF FIGURE"},
but replace the page numbers with locators like "Figure 1.1".
For a better result I recommend the method described later for section numbers, but a faster and possibly simpler method
is to copy your captions into a new document, and then place each figure (or listed item) on a separate page.
Make sure all your page numbers match your figure numbers (or whatever), and run the index. For example,
you could number your pages 1.1 through 1.12 for the first twelve figures, 2.1 through 2.12 for the next
twelve figures, or whatever. Put one figure on each page, such that Figure 2.2 is actually on page 2.2.
When you run the index, Word will use these artificial page numbers, which is what you want. Now just
make sure you put your index entries on the appropriate pages, using whatever text you want.
The danger of this method, despite its ease, is that you must now manage two documents: your original
text, and your figures. If you are going to add, delete, move, or renumber any of your figures, your
index won't be accurate.
For many-to-many lists.
Here's an example that's quite similar to the one-to-one method,
answering a question I received by email: "We are publishing a bibliography
that will consist of dozens of numbered paragraphs. I intend to create an index at the end
of the bibliography so the reader can search alphabetically for the authors. I know that
the index can list the page numbers on which the indexed names appear, but can it list the
numbered paragraphs instead? (In other words, rather than see that “Doe, John” appears on
pages 116, 117, and 120, can the index show me that his name appears in bibliography
entries 24, 32, and 40?)" The difference between this example and the figure example above
is that the person asking this question is interested in having multiple entries for each entry.
Where the list of figures has one entry per figure, this author index will do more than create
multiple locators for each name; it will also allow multiple entries for each reference.
This many-to-many mapping is exactly what indexes are supposed to do, making this is a GREAT
example of why {XE} fields are the right tool for this job.
One solution to this author index challenge is to make sure that
each bibliographic entry appears on its own page, and that the pages match the items. Thus bibliographic
items 24, 32, and 40 should be on pages 24, 32, and 40 respectively. Create your index entries
for each item, one entry for each name (as you would want it to appear), and don't do anything
unusual; even though your pagination is weird, your indexing shouldn't be.
Generate your index as you would normally. In a sense, you are tricking Word into using
your bibliographic record numbers because you are making sure your page numbers match them exactly.
This many-to-many product is easier than the one-to-one example above for a few reasons.
First, you don't have to make sure that this secondary document matches your original documentation
perfectly. As long as the authors names haven't changed (e.g., been misspelled then corrected)
and numbering remains the same, you're all set. But if you're going to be adding, deleting, or reordering
items within the bibliography, or if your author names are likely to change, you should wait for something
more complete before generate this index. Second, you aren't working with funky multipart page numbers
like 1.1, which require some effort to produce. Instead, you're just counting, starting with 1.
For indexes that use section numbers for locators.
A totally different kind of documentation product that doesn't use page numbers is one that uses
paragraph or section numbers, like 4.1.1.3. You can't use Word's indexing feature naturally to create these,
because Word will grab page numbers, not section numbers. And you can't use the table of contents
feature because (a) you can't have multiple entries pointing to the same place and (b) you want
your items sorted alphabetically, among other reasons.
If you're not going to build a page numbering system that exactly matches your section numbering system
-- and you shouldn't -- then you need to hijack the indexing system entirely. You need to create index entries
that uses the section numbers as if they were entry text, and then perform some search-replace magic on the result to build
what you intended to build.
For example, imagine that all of your index entries were of the form
{XE "main entry:optional_subentry:optional_subsubentry:sectionnumber"},
like this:
{XE "indexing:with Microsoft Word: :4.1.1.3" \t}
.
Notice that this example has a sub-subentry of just a single space. Also note the use of the \t
flag, which suppresses creation of any page number. Consequently,
when you produce your index, you'll have all your locators (section numbers) appearing
at a sub-sub-subentry level, but no automatic page numbers.
Then, thanks to Word's styles, you can search for all
instances of the Sub3 style (or whatever style is applied to sub-sub-subentries), and make the magic changes
to produce an index that looks like this:
main entry
with Microsoft Word, 4.1.1.3
To do this properly you'll need to (1) globally search for Sub3 styles and prepend a word like REMOVEME, plus a comma and space;
(2) remove all space-only entries; (3) delete REMOVEME plus the preceding paragraph marker to run up the locators.
Thus you'll go from uncombined entries like these:
main entry
with Microsoft Word
4.1.1.3
4.2
10.1.9
to
main entry
with Microsoft Word
REMOVEME, 4.1.1.3
REMOVEME, 4.2
REMOVEME, 10.1.9
to
main entry
with Microsoft Word
REMOVEME, 4.1.1.3
REMOVEME, 4.2
REMOVEME, 10.1.9
and finally to
main entry
with Microsoft Word, 4.1.1.3, 4.2, 10.1.9
Now there is still one remaining problem, and that's what happens when you use section
numbers that move into double digits. Word likes to sort numbers by their digits and not their
numeric value, which means you get sequences like this: 15, 5, 501, 52. With section numbers,
you can end up with garbage where 10.1.11 comes before 10.1.2. To stop this from happening,
you need to add zeroes in front of all one-digit numbers, so that everything is a two-digit number.
(If you have and three-digit numbers, you'll need to add even more zeroes.) So instead of
using 10.1.11, you'll use 10.01.11. And then, when you've generated the index, you can search for
all occurrences of ".0" and replace them with just ".", essentially dropping all those extra naughts.
You can, but you won't like them. Using Word to create them will create heads that match your
first full-line entry on that page. In many cases, this means your dictionary-style headers
will have page numbers: "My Entry, 16, 76, 79." If you want to truncate those page numbers
so that you have only "My Entry" at the top, I don't know how to do it. I suspect it can't be
done either, given how Word doesn't differentiate well between the entry text and the locators.
Thankfully and in all practicality, you do not need dictionary heads in an index anyway.
Indexes are easy enough to read, scan, and browse, just by looking at the terms at the tops of
the columns. However, you must add continued lines when the page breaks appear in
between main headings, so that the term at the top of the left page's first column
is always a main heading. Unfortunately for us all, this is a manual exercise.
(What's a continued line? Read my instructional document on
line, column, and page breaks.)
I am occasionally asked how to keep tabs inside an index entry. For example, one questioner gave me this example.
He wanted to create
{ XE "Graham, John Jefferson Obituary 5 January 1933 (Front Page)" }
so that later he would have a two-column result, which he could use to build a table. This is a fascinating
"abuse" of the indexing feature, and I'm all for it -- but unfortunately, Word doesn't maintain tabs in the
entries. They get deleted when you try to create the index:
Graham, John Jefferson Obituary 5 January 1933 (Front Page)........137
The trick is to not use an actual tab, but rather use some set of unique characters that later you can convert
into tabs, once the index is generated. For example, I would use PUTTABHERE in my XE field.
You might prefer to add spaces around this term as well, for readability, but they're optional:
{ XE "Graham, John Jefferson PUTTABHERE Obituary 5 January 1933 (Front Page)" }
This will give you
Graham, John Jefferson PUTTABHERE Obituary 5 January 1933 (Front Page)........137
and then you can use Find/Replace to remove the PUTTABHER term (with spaces, if you added them) with
the tab character ^t. That will give you your first two columns. The page numbers are already in their
own column, if you used the .... styling shown above (it's a setting in the index creation dialog). Just
change the right-justified tab you have in your ruler with a left-justified tab, and you're all set. You can
also change the style of the tab so that it doesn't include all of those periods. The result is a three-column table:
Graham, John Jefferson Obituary 5 January 1933 (Front Page) 137
that should get you to where you want to go.
Don't forget that any time you make manual changes to your index, updating the index will delete all of this layout work.
Just to say your tip sorted out the errant fonts within my index, which is great. What a brilliant resource your site is. Many thanks. ---George
If you want to search within your {XE} fields, such as to correct stray spaces, then it helps to find only those fields
that are {XE} fields. Word allows you to find fields using the ^d code in the Find box; I use this often to
turn all my fields purple, effectively highlighting my index tags for added visibility (see Using colors for XE fields).
However, if your document has fields other than {XE} that you want to avoid, skip, etc., then searching for whatever matches ^d
isn't good enough.
Margaret's approach (using Word 2003) to finding only the index fields involves a nifty trick: make field codes invisible, but hidden visible. In other words,
uncheck the check box for Tools > Options > View > Field Codes (in the Show group of the Options dialog), and check the check box for
Tools > Options > View > Hidden Text (in the Formatting Marks group of the dialog). Now you can search for ^d and find index fields exclusively.
If you are going to turn your index tags into another color (for editing), now's your chance.
One of nastiest problems with indexing within Word is that you can't conveniently spell-check your index. If you try to spell-check your document, you'll stumble across
all the convoluted syntax of colons and semicolons and you're spell-checker won't know what to do. And if you attempt to spell-check the generated index, it will full-out fail,
because a generated index is hidden from your spell-checker. Argh! Blast!
There are two ways to spell-check your index, and both are pretty ugly. The first is to copy the index into another document, but using Paste Special and pasting as unformatted text.
You can spell-check the result, although it won't have any of the indentations and text formatting. Also, if you find something misspelled, you must then go back into the documents
to find the misspelling to correct it; in other words, making changes to the copied text is pretty useless.
A more integrated but challenging approach is to convert your uncheckable indexing entries into checkable indexing entries, by temporarily manipulating the syntax, spell-checking, and then
putting the syntax back where it needs to go. For example, since you can't spell-check {XE "Halloween:kids and"} because Halloween:kids is perceived as a single misspelled word,
you need to edit it to {XE "Halloween : kids and"} so the words can be seen individually -- and then remember to change it back! Here's how. First, you need to format all
of your {XE} fields into a unique format; I recommend a color. Instructions on doing this are available at Using colors for XE fields.
Then, search for all purple colons and change them to purple colons with spaces around them; do the same with semicolons and any other indexing syntax used in your index that interferes with spelling.
Now that you've pushed your colons
and semicolons out of the way, the words of your {XE} fields are accessible to your spell-checker. (If you have many documents, you'll have to do this for each of them individually.)
Spell-check your documents now; make sure you make your corrections consistently. And finally, once your checking is complete, search for purple colons with spaces around them and replace them with colons;
same with semicolons and other syntax.
The advantage of this latter approach is that you are editing the tags themselves; every correction you make is made in the right place. However, there is one major downside to this approach, and that's
your interpretation of all colons and semicolons as syntax. If you index has lots of non-syntax colons in there -- for example, maybe you are indexing Bible verses -- you need to be careful
that changing and then unchanging the spaces that surround them can introduce unexpected errors. Another issue is if you try to put spaces around your quotation marks. This isn't necessary for spell-checking,
so it shouldn't be a problem, but adding/removing spaces around quotation marks (and apostophes) can convert straight quotes into curly quotes, or accidentally curl your quotes in the unpreferred direction.
Yes, you can. Microsoft Word can make all hidden-text codes visible, whether they're for
indexing or not. Go into Page Setup (available from the File menu) and look for something
that says "print display codes" or "print hidden text" or something like that. Until you
uncheck that box in the future, all of your codes will show up in your printouts.
Be aware that printing with your indexing fields visible will affect the pagination.
Don't write an index using your hard copy this way.
On a related note, remember that you can track changes when you work.
Every time you insert, edit, or delete an XE field, you'll get a note in the margins.
These marginal callouts can speed up your ability to find your XEs, although it might
also clutter up your work. Use Tools > Track Changes to turn that feature on.
Additionally, these changes can be made visible when printing as well, using a similar
process as described above. Keeping XEs invisible but marginal notes visible allows you
to see the index pointers without messing up the pagination. Be warned, however,
that if changes are already being tracked, don't turn that feature off! You could lose
that information for good. Instead, use the View menu to make those changes visible.
You can, but you have to do it manually after you've generated the index.
I don't know where within the Word settings the word "Index" -- which appears at the top of a generated index --
is defined. If it were possible to find that variable or registry key, I'd love to know about it.
Anyone have an idea?
Yes. The character used in between locators in page ranges is controlled using a tag in the {INDEX} marker. it's the \g flag. See my Wordflags page.
Here's a related and helpful tip, given to me by technical writer Susan J. Dorey. If you're worried about word-wrapping, then you probably don't want to use a regular hyphen as a delimiter. After all, hyphens are prime candidates for Word's line breaks. Instead, use a nonbreaking hyphen as your delimiter.
If you're working as part of a production team, you might find yourself in the unpleasant situation
of indexing a document only to find it has been replaced with a new version. For example, you might
be in the middle of indexing a draft version, or secondary copy, when you are suddenly
faced with a new version that has no index data in it. What's the easiest way to copy your index
data into the new document?
The easiest way is the only way, unfortunately. You have to copy and paste it all. What's worse is that
you have to paste it carefully. If the text between the two documents is very different, your index
data may need to be put in a different location. Additionally, your index data may be obsolete, if the new Word
files contain noticeably different content. For these reasons it would be helpful to have the two documents
side by side, if you can. And if the documents are really close together in content, you might
use tracked changes to update your draft instead of copying over your index.
The only helpful tip I can offer is that you can search for fields. In your draft version, search for a
field (such as the XE fields) and then use Ctrl-PgDn to find the next one. At least this way you can jump
from one index field to the next in the source document. In the new (pasting) document, however, you'll
still have to search.
I received an email with this question: "The page numbers in my index appear in the correct format (Index 1, Index 2, etc.), but the heading text appears with the characteristics of the style it has been assigned in the document (Header, Body Text, Italic, etc.). Is there something that I am missing as I set up the Index format?" Wow, sometimes Word really is a stupid program.
If you are getting lots of different styles and formats in your generated index, then you likely copied and pasted data into the XE fields. This happens not only when you enter tags manually (without using a dialog box), but also when you highlight the text select the Add Entry command. Or perhaps you are creating the XE fields in the paragraphs in some other way such that styles were retained. Regardless of how you got there, the heading data inside your tags is inconsistent, which is why the result is so strange. You have two easy fixes to fix this problem. Option A: Find all instances of the markers and apply a different font or style to them; search and replace can do this as long as you don’t have lots of other kinds of tags in your docs. Option B: Globally fix the style of the index once the index has been generated; being a manual fix, updating the index will undo this work, so you want to do it once only. I strongly recommend Option A.
Your site solved a formatting issue that had been plaguing me for over a week. No one else out there, certainly not Microsoft, had a clue how to fix it. Thank you! ---Chris
Okay, you probably read the question and answer immediately above, Why do the lines of my generated
index have different styles?, but still you want an actual FIX to the problem. For example, you've just created an
index tag (XE field) and just by looking at the blasted thing you know it's wrong. You want to fix it. You no
longer care why it's a problem, you just want to make the problem go away. Well, I have a few suggestions.
Before you go totally nuts, you should know that the appearance of the tag as a whole rarely has any effect on the appearance
of the index data when you generate the index. For example, if you insert an XE tag into a figure caption, the
font and font size of the entire tag will be caption-appropriate and blend in nicely, without changing the font or font size
of the resulting text. However, if the curly brackets and letters XE look comparable to what's in the paragraph, but the text
inside the XE field doesn't look right -- wrong font, wrong font size, some combination of both -- then you'll want
to look at different ways of creating or editing that field. because if you don't, those weird fonts will end up in your index.
Now I don't know how you put that XE field there in the first place, but we're going to try everything. First, try creating a new field using Word's menus, like Reference > Add Entry. If that doesn't work, instead try copying an XE field from
elsewhere in your document -- one that formats properly, of course -- and pasting it where you want the new one to go. If that appears to work, then edit the text to create the field you want. And if that doesn't work, then use Format Painter (the little
Paintbrush icon in the ribbon) to grab the format of an XE field you like and paste it onto the XE field that's
driving you nuts. And finally, if none of those things work, you might want to investigate why the style of the paragraph you're
indexing is totally different from other ones. In other words, it's not longer an indexing issue; it's a styling issue.
Now this is the kind of question asked by people who understand indexes! The goal is to create an index that uses indentations
for the highest subheads, but uses run-in style for the lowest subhead level. For example, suppose you have an indented
index that looks like this:
However, because of space constraints or some other reason you want to combine all of those sub-subheadings onto the same line,
in what is called run-in style or paragraph style. The result looks like this:
There is no way to do this automatically. With Word, you must choose between indented and run-in styles up front, and you can't take
a half-and-half approach like this. But we can do this quickly once the index is created. If you are using styles, the lowest level
of your index should have a unique style like Index3 or Index4, depending on how deep your index gets. To run-in the lowest level of
your index, select the appropriate style (say "Index3") and use Find/Replace. Replace all occurrences of ^p (the code for
a paragraph marker) of style Index3 with a semicolon and space (; ). This will enable you to build the hybrid style above from the
indented-style index shown.
Strictly speaking this is not proper run-in style. In proper style, the word "keyboard" would be run up to the level above, like this:
This is more complicated, because the paragraph symbol you want to delete is of style Index2, but you only want to remove Index2
paragraphs when they are followed immediately by Index3 text. You can do this, but it takes a few steps. First, search for
any instance of Index3 and replace with DUMMYTEXT^& to add the phrase DUMMYTEXT in front of the sub-subheads. Then do
a global search (no styles) for all occurences of ^pDUMMYTEXT and replace with period and space (. ). That should do it.
Note that if your index has cross-references, you'll need to deal with those separately, but using the same basic approach.
Don't forget that any time you make manual changes to your index, updating the index will delete all of this layout work.
Microsoft Word has a useful feature to make all hidden-text codes visible, for those times
when you want to be able to print them. Or maybe you want to write your index without having
all of your hidden text visible and cluttering up the screen. To make them visible,
go into Page Setup (available from the File menu) and look for something
that says "print display codes" or "print hidden text" or something like that. To make them
invisible, uncheck that same box.
The index-related reason for this is simple: you have XE fields in your table of contents.
Creating index entries in your table of contents is like ripping the fabric of space and time.
There are two specific behaviors that lead to this problem.
First, if you build the TOC and then you start auto-marking to build your index, you'll end up inserting XE fields into the table of contents.
And if you don't know how I feel about automarking [it's disastrously misguided as an indexing tool], then please read Auto-Marking: What Good Is It?.
The other way you can get XE fields into your table of contents is if you have added them in your document's section headings. This also happens if you use automark
(stupid, stupid functionality), but it can happen if you put them there manually, too.
To solve these situations, you need to find a way to get into the document. Open it with NotePad or some other tool and delete the table of contents manually.
Then, if you have XE fields in your headings, remove them.
A million thanks for your guide to indexing at your website. My 300 page Word document continued to crash every time I added the index. Your diagnosis that indexing entries in the TOC created the problem was right on. ---Soin
If creating your index seems to erase, undo, or override your headers and footers, then you probably have a section-related problem. Indexers are created
in their own sections, and sections can sometimes inherit headers and footers from other sections; there's some sort of perfect storm here.
(FYI, this issue came into my Inbox on October 2010, and I took my best guess. Apparently I was right; see the accolade from Sara below.)
Here's your solution. Take your messed-up document with index, and then undo or remove the index. Don't fix your headers/footers throughout just yet, but you'll want to do that shortly. Create a new section at the end of the document. Check the header/footer information, so that it’s independent. (You have to turn of the “same as last section” option, or whatever it’s called.) Then drop the index into this new, independent section. Now go and fix your document's headers and footers throughout. The key is that the index section is not inheriting or overriding other document sections.
I'm telling you very loudly YOU ARE MY HERO! This is another problem with Word index that I've had for years. I just manually went back and put the page numbers in again. You were right about making it a separate section. That's all I needed to do. I would definitely put that into your FAQs! ---Sara
Keeping up with software that is frequently re-released can be difficult, although to date Microsoft has awarded very little attention to indexing tools and functionality.
(They seem to think indexes aren't important enough in the grand scheme of things, can you imagine? :-)
To maintain this document, then, I'd appreciate your help. Email me with corrections, clarifications, anecdotes, and your special tips and tricks. I'll append them to this document.
My email address is seth@maislin.com. Thank you.
and the INDEX \f flag