Most of the time I can take care of unattractive line breaks in the TOC by putting in non-breaking spaces in a paragraph.
However, I sometimes have a situation where the text of a TOC entry is too close to the page number on the right. The text is so close to the page number that in some cases no leader dots show, or only one or two leader dots show.
The entry and its page number fit on a single line, so putting in non-breaking spaces won't solve the problem. I could put in a soft return (Shift-Enter) in the TOC entry to force a line break, but it isn't efficient because I have to put in the soft return manually each time the TOC is updated.
If anyone has a tip on how to handle this problem efficiently, I'd love to know about it.
Awhile ago, someone posted a solution for getting nice line breaks in index entries. It involved setting the maximum and minimum word spacing values in the paragraph designer. The values posted there did not work for me, so I played around with it and use the following:
In the paragraph format for the TOC entry, set the maximum word spacing to 325% and the minimum word spacing to 275% and the optimum spacing to 100%. Note the fact that the optimum is NOT between the maximum and minimum values. I do not know the algorithm that Frame uses to decide where to break the line, but I am guessing it first decides to break the line to fulfill the max and min requires, breaks the line, but then changes the spacing back to 100%, which is what one wants, that is, one does not want wide spaces.
The above values causes a line break about an inch or two from the right margin. If you want it closer, try 225% and 175%. I found that the larger these two numbers the line breaks occur farther from the right margin.
This method avoid having to enter manual line breaks and gives a nice line break, even for lines that could fit on a single line.
Your solution is an amazing, fantastic gem! Thank you so very much!
That is absolutely brilliant. It also seems to prevent multi-line TOC entries from encroaching on the page number area in general.
For ages I thought the only way around this ugly problem would be to wait 200 years for Adobe to give us four different indent options (first line left, left, right, and last line right) instead of the three that we currently have. (Last line right doesn't exist.)
I'll just add one more suggestion that might make your line breaks and page number positions in the TOC 100% automatic instead of merely 98%.
(It doesn't sound like much of an improvement, but if you've ever had to manually adjust the TOCs for 50 manuals every time you regenerated them, then you'll know where I'm coming from.)
If you have any TOC paragraph specifications that use more than one tab, for handling section or chapter numbers at the front of the paragraph for example, then you'll notice that if a TOC entry wraps to two or more lines then the page number will no longer be printed at its intended tab stop, but will use one of the earlier tab stops instead (because in the new line there are no longer any previous tab characters to fill the earlier tab stops).
The cure for this is to go to the TOC specification flow on the Reference pages, and in the problematic paragraph format add an extra tab character in front of the <$pagenum> building block.Then...
If the TOC entry only covers one line, the extra tab character will be ignored.
If the TOC entry covers two or more lines, the extra tab character will be used to fill up the previous stop so the page number settles at its intended tab stop.
If you have TOC specifications that rely on more than two tab positions, just add more tab characters in front of the <$pagenum> building block (and regenerate) until the page number (in multi-line entries) lands at the correct tab stop.
Thank goodness FM uses absolute tabs and not relative ones.
On a related note, to keep page numbers from breaking to the next line on their own, on the Refernce TOC page, insert a non-breaking space (esc space h) just before the pagenum variable.