home > indexing
Troubleshooting Those Horrible Microsoft Word Index Problems

By Seth A. Maislin
Most recent significant updates made in March 2011

  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.

 Jump to:

About page numbers and page ranges
My page numbers are all wrong!
My page ranges aren't working
Can I change my page lists to page ranges?
Can I create page numbers like 135n12 for footnotes or endnotes?
Can I create an index with something other than page numbers?

About headings and whole entries
Identical entries are not combining properly
Identical-meaning entries are not combining
How can I change all my entries to uppercase or lowercase?
Index entries aren't showing up in the index
My index entries suddenly vanished
Can I delete all my ___ entries? UPDATED
Why can't I get certain characters into my headings? NEW

About sorting
Individual entries are not sorting where you think they should
How to override Word's default sorting
   includes Value-Sorting Numbers NEW
All of my sorting is wrong!
My letter categories are wrong, weird, or simply not what I want

About format and layout
Why can't I hyperlink my page numbers? NEW, PARTIALLY UNSOLVED
My cross references aren't positioned or formatted correctly
My continued lines vanished
How can I keep my tabs in my index entries? NEW
Can I create dictionary-style heads (guide words) in my index?
Can I call my index something other than "Index"? UNSOLVED!
Can I control the hyphens in my page ranges? NEW
Why do the lines of my generated index have different styles?
How do I stop my XE fields from inheriting the wrong formats? NEW
How can I build a hybrid indented-style/run-in-style index? NEW
Creating the index erased my headers and footers! NEW

About the whole index
My entire index suddenly vanished
How do I create multiple indexes from the same documents?
My two indexes aren't working NEW
How do I get the index to appear after the endnotes? NEW
How do I spell-check my index? NEW

Productivity Hints
Using colors for XE fields NEW
Quickly building cross-references for initialisms NEW

Tools and techniques
I can't hide my XE fields
How do I display the INDEX field? NEW
Auto-marking: what good is it?
Teaching auto-mark to ignore or consider certain things
Can I print my documents with the XE fields visible?
What's the easiest way to move index data between documents? NEW
Can I index without having to see all the whitespace marks? NEW

I have a question that's NOT about the index

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.

 Jump to:
I indexed, and now the file crashes on me UPDATED
Creating the index erased my headers and footers! NEW

  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.

My page numbers are all wrong!

  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 
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 
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 
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

Identical Entries Are Not Combining Properly

  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:
    Washington, George, 33
    washington, George, 37, 39
    Washington, George, 44
    Washington, george, 46
These can be hard to catch, so look closely.

  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

Why Can't I Hyperlink My Page Numbers? NEW, PARTIALLY UNSOLVED

  Simple: Word doesn't allow it. Dumb, stupid Word.

  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

Identical-Meaning Entries Are Not Combining NEW

  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.

Individual Entries Are Not Sorting Where You Think They Should
(and then, how to override what Word wants to do)

  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.

  How to Override Word's Default Sorting There is an undocumented feature that allows you to apply manual sorting overrides for your entries. Follow the entry level that you want differently sorted with a semicolon and the sort text itself. In the example below, the main heading will appear re-alphabetized as if the text of the main heading were actually "resortedmain." The subheading is also re-alphabetized as if it were spelled "resortedsub."
     {XE "main;resortedmain:sub;resortedsub:sub-sub;resortedsub-sub")
Note that if you're familiar with the syntax for embedded indexing with Adobe FrameMaker, this is significantly different. With FrameMaker, you would write the complete entry, followed by the semicolon, followed by the complete resorted entry. With Word, however, you apply the resorted text to each level individually. In general, you will want to override the sort for only one level; my exaggerated example above overrides all three levels. And as always, remember that spacing counts, so don't insert spaces that have no meaning.

  Value-Sorting Numbers. One question that comes up with regular frequency is how to ensure a numeric sort, 0, 1, ..., 9, 10, 11, ..., in favor of Word's default digit-by-digit sorting of 0, 1, 10, 11, ..., 19, 2, 20, .... The answer is straightforward: provide a sort override for your digits with leading zeros. Thus you'll want to use 03 to sort 3rd in front of 10th:
     {XE "Massachusetts:3rd district;03")
     {XE "Massachusetts:12th district;12")

  I have recently found your website and am very impressed with your expertise in Word indexing.  Your help on over-riding Word's way of sorting within the index is awesome.  It's crazy that it is undocumented.  ---Thomas

All of My Sorting Is Wrong!
Submitted by Iain Scurrah

  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:
	   , 395
	Deep history points, 137
	   Importing, 102
	Interfaces, 102
	Design-time environment
	    , 395
	, 244
	, 244

  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.)

  For instructions on how to remove all Tracked Changes once and for all, visit http://office.microsoft.com/en-us/word/HA012190211033.aspx

  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

My letter categories are wrong, weird, or simply not what I want NEW

  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.

Index Entries Aren't Showing Up in the Index

  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:
   WRONG:   {XE "Luke 9:21, interpretation of"}
   CORRECT: {XE "Luke 9\:21, interpretation of"}
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 flagopens in new window and the INDEX \f flagopens in new window. You can read about other flags as well in my MS Word Flagsopens in new window 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

My Page Ranges Aren't Working

  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 pageopens in new window.) 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.

Can I Change My Page Lists to Page Ranges?

  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.)

My Cross References Aren't Positioned or Formatted Correctly

  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 flagopens in new window, 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.

My Entire Index Suddenly Vanished

  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 flagsopens in new window 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.

My Index Entries Suddenly Vanished

  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.

My Continued Lines Vanished

  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.

  (What's a continued line? Read my instructional document on line, column, and page breaksopens in new window.)

I can't hide my XE fields NEW

  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.

Can I delete all my ___ entries?

  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.)

Why can't I get certain characters my headings? NEW

  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.)

How Can I Change All My Entries to Uppercase or Lowercase?

  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

How do I create multiple indexes from the same documents?

  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
     {INDEX \f "name"}

     {INDEX \f "subject"}

  where the indexes could look like these:

     heading1, 987
     heading2, 987

     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

My two indexes aren't working together NEW

  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.

How do I get the index to appear after the endnotes? NEW

  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.

How do I display the INDEX field? NEW

  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.

Auto-Marking: What Good Is It?

  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.)

Teaching Auto-Mark to Ignore or Consider Certain Things

  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.

Can I Create Page Numbers Like 135n12 for Footnotes or Endnotes?

  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
               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.

Using colors for XE fields

  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.

  If you need to make sure you color only your {XE} fields -- which is important if you do have lots of fields -- then read "Can I See (or Search) {XE} Fields, But Not Other Fields?".

  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.

Quickly building cross-references for initialisms NEW

  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.

Can I Create an Index with Something Other Than Page Numbers?

  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 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: :" \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,
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

    main entry
        with Microsoft Word

                REMOVEME, 4.2
                REMOVEME, 10.1.9
    main entry
        with Microsoft Word
                REMOVEME, 4.2
                REMOVEME, 10.1.9
and finally to
    main entry
        with Microsoft Word,, 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 rock, Seth! Thank you! ---Michelle

Can I Create Dictionary-Style Heads (Guide Words) in My Index?

  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 breaksopens in new window.)

How can I keep my tabs in my index entries? NEW

{ XE "Graham, John Jefferson                  Obituary 5 January 1933 (Front Page)" }
Graham, John Jefferson Obituary 5 January 1933 (Front Page)........137
{ XE "Graham, John Jefferson PUTTABHERE Obituary 5 January 1933 (Front Page)" }
Graham, John Jefferson PUTTABHERE Obituary 5 January 1933 (Front Page)........137
Graham, John Jefferson              Obituary 5 January 1933 (Front Page)            137
  I am occasionally asked how to keep tabs inside an index entry. For example, one questioner gave me this example. He wanted to create

  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:

  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:

  This will give you

  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:

  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

Can I See (or Search) {XE} Fields, But Not Other Fields?
Submitted by Margaret Berson

  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.

How Do I Spell-Check My Index? NEW

  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.

Can I Print My Documents with the XE Fields Visible?

  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.

UNSOLVED: Can I Call My Index Something Other Than "Index"?

  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?

Can I Control the Hyphens Used in My Page Ranges?

  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.

What's the Easiest Way to Move Index Data Between Documents? NEW

  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.

Why do the lines of my generated index have different styles? NEW

  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

How do I stop my XE fields from inheriting the wrong formats? NEW

  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.

How can I build a hybrid indented-style/run-in-style index? NEW


        buying, 222
        hardware, 111
            keyboard, 113
            modem, 115
            monitor, 120-1
            mouse, 112
            printer, 122
        troubleshooting, 333

        buying, 222
        hardware, 111
            keyboard, 113; modem, 115; monitor, 120-1; mouse, 112; printer, 122
        troubleshooting, 333

        buying, 222
        hardware, 111. keyboard, 113; modem, 115; monitor, 120-1; mouse, 112; printer, 122
        troubleshooting, 333
  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.

Can I index without having to see all the whitespace marks?

  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.

I indexed, and now opening the file crashes UPDATED

  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

Creating the index erased my headers and footers! NEW

  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

Request for Comments and Other Feedback

  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.


Copyright 2006-2011 Seth A. Maislin


Site design by little graphics studio.
© 2010   All rights reserved.