Sever the Link to the Table of Contents So it Won’t Get Replaced
There’s just no way around it: Sometimes you have to edit a table of contents that you’ve generated (using Layout > Table of Contents)… and sometimes you have to edit it a lot. For example, perhaps you want some special order to the paragraphs that is different than the way it appears in the document pages. Or you want to edit the text a lot. Or you want to remove a bunch of shift-returns that snuck in.
But once you edit the TOC, your changes are in danger of being wiped out. It just takes someone choosing Layout > Update Table of Contents and all your work is gone. Gah. So how can you sever the connection to the table of contents, so that the Update feature (and the Replace Existing Table of Contents feature) doesn’t work anymore?
The answer is surprisingly simple: Select all the text in the table of contents story, cut it to the clipboard (Cmd+X), delete the text frame, then paste the TOC into a new text frame. It’s the frame, not the story, that is linked! So getting rid of that frame (or even just the first frame, if it’s a multi-page, threaded TOC) will sever it.
 |
That sure is the quickest way that I know of too. :)
In fact, before I use “Update TOC” I make a duplicate of the current TOC out to the pasteboard. Just in case!
Although – in the grand scheme of things – it might be best to fix all those annoying shift returns in the actual text itself instead of in the TOC.
I know it’s more time consuming. But if you’re making a lot of Updates to a TOC via the “Upadte TOC” command it would be worth it.
And I know it’s been covered elsewhere, but it’s worth keeping that linked TOC on the pasteboard if you want to use it to generate PDF Bookmarks. In fact, even if you are doing the whole visible TOC manually, creating one on the pasteboard is the quickest way to create PDF bookmarks for section heads.
re ‘a bunch of shift-returns’: I recall a comment or article from some years back that suggested using a right indent to wrap long titles. If one does so, the item in the generated TOC has no unwanted line breaks.
If i generated TOC in a same frame, we dont want to repaginate again is it correct. I don’t know understand can you send me the Videographical demo.
Mani
Duplicating or alt-dragging a Contents frame is simpler than cut/paste text and has the same effect of breaking the link.
To avoid soft returns showing in Contents, you can often use non-breaking spaces or change the width of your heading frames if they are separate to your copy. Can also use a blank frame on your pages with text wrap to force a line break (bad, old school style!).
Late to the party… but since I work a lot with translated documents I see first hand the extra work needed when the TOC is badly formated, linked or not.
To avoid line breaks (shift-returns) in headings, which will subsequently turn up in the TOC, start by simply turning off hyphenation in the heading formats. All of them. A staggering amount of line breaks in headings is put there just to avoid hyphenation. Depending on design, I would say we’re talking about anything from 40-90 per cent. Turning off hyphenation means you won’t have to put that line break there to begin with. It’s unnecessary work! Not mentioning how much unnecessary herding of meaningless or misplaced line breaks that is needed in the translation afterwards (oh, I just did…)
The TOC formats should have hyphenation turned off as well, for the same reason.
Another simple solution to make TOCs look good without lots of manual work is right indents combined with “flush right” tabs. When an entry needs more than one line because of the length of the heading, the right indent will protect the line from getting too close to the page numbers, and “the flush right” tabs (shift+tab, ^y in the TOC format) will keep the numbers t the far right in the text frame. Just set the right indent to your desired distance and change the separator character to ^y instead of ^t.
Ooops, sorry, I didn’t have InDesign handy and forgot to mention a tiny but important detail about that right indent for the TOC: it doesn’t work unless you also assign a “minus indent” on the last line. It works just like a hanging indent, but reverse, if that helps.
So if you assign, say, 10 mm right indent to the TOC style(-s), also assign -10 mm _last line indent_. If you don’t, the page numbers will move inwards with the right indent, and that’s not what we wanted.
Aaagh, assign last line minus indent to the TOC _Paragraph Style(-s). The right indent and last line indent is a paragraph style setting, you don’t specify it in the TOC style. Reading what I wrote someone might think otherwise. Sorry, trigger happy, too much coffee…
Scrivi il tuo commento Puoi usare questi tags HTML : <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <strike> <strong> var RecaptchaOptions = { theme : ‘red’, lang : ‘en’ , tabindex : 5 }; #submit {display:none;}
Thanks for this tip; I will add it to my list. I have been searching and searching for the answer: when exporting as ePub, ID puts the Contents AT THE END of the document. And the TOC needs to be updated multiple times as I work out the layout and the Styles for it.
Popping the new TOC into a text box, however, once again forces it to the back of the ePub conversion.
Once you figure out how long the TOC is, and how many pages are needed, you can insert those pages and cut/paste the generated TOC _into_ the flow. This will make a linked TOC in the ePub conversion. Yes, you’ll have to do it a few times, probably. But it works to solve a ridiculous problem generated by the technology of the TOC tool. I wonder if Affinity has the same issue?