TOC Tab Fill Characters Stop Being Used For New Entries

Using Version: 6.1.2.1 Build ID: Gentoo official package, rendering the Table of Contents causes the Tab Fill character to not be included in level 3 entries that have been added more recently within a particular level 2 entry. Instead the TOC rendering uses a fill-character-less right tab for those new entries. All other recent entries for levels 1-5 produce the tab fills as configured, with leading dots and the page number aligned to the right margin. Has anyone else seen this behavior? Is there a circumvention?

More data: I recreated all the broken level-3 headers with "Redo " prefixed into the set text variable that constitutes the text of the header (this variable is displayed in the page footers). That produced the expected rendering when the TOC was rebuilt. Then I started editing the headers’ variables to elide the "Redo " prefix and that caused the mis-rendering to return to each after it was edited back to the original string and the TOC was rebuilt.

Note the new headers originally created with the "Redo " set variables were all typed freshly–no strings from the original headers were copied and pasted. The problematic values (all filenames) are: batlog, batstat, batuploop, batuptime, editfile, mntdrvs, rate.awk, etc.fstab, and etc.hosts. Also, I promoted batlog to level 2 and the mis-rendering persisted. “1st batlog” fails but “2nd batlog” renders properly.

Quite difficult to understand from your description. Can you attach a short sample file with the symptom? I upvoted the question to grant you karma points.

Thanks for the comment! I guess I must attempt to produce a small demonstrator out of the 162-oage doc with a 5-page TOC. I’ll gut the body of a clone and see if a few headers will cause the misbehavior.

I was successful, although it misbehaves differently from the original (the original behavior is described in the non-header paragraphs associated with each header. It’s ~20K and available at [link text](http://dlc.casita.net/~dlc/TOC_With_User-Variable_Tab-Fill_Defect_Demo.odt"at this URL") but I’ll be happy to upload it elsewhere if somebody will give me the particulars.

First, the good news: your TOC behaves absolutely as expected, but you ran into a misregarded Writer subtlety.

Next, I scorn you because your document structure is uselessly complicated. You surely spent a lot of time to recreate existing features.

It would have been easier to style your headings with built-in Heading n (this is the intended use for these styles). Though built-in, they can be customise any way you like, just like user styles. You can even link them so that they inherit from their ancestor (just like you did with your custom style).

Where the pain comes in is you had to design your own numbering style, aka. list style, instead of playing with Tools>Chapter Numbering to customise your heading numbering. Since you have only one numbering category in your toc (numeric without alphabetic appendices for instance), it would have been simpler and better maintainable.

  • Now to the heart of the problem, i.e. your CCH-Hn paragraph and CWH list styles. They contain conflicting parameters. In the paragraph styles, you defined increasing Before text indent (with H1 = H2) and ad-hoc First line indent to align numbering. Your CWH mandates that the numbers be followed by a tab which stops at 1.27cm. But, beginning with level 3, your heading numbers are already wider than the spacing defined by this tab stop. This means that the tab will stop at the next default one.

You should tune your tab stop setting to make sure the widest number will be contained inside this space, before the Before Text indent defined in the paragraph style.

Note: you set Alignment to Justified which is not recommended for headings (in the case of multi-line headings).

  • Next, your TOC. It suffers the same phenomenon. Instead of using built-in Contents n, you created CCH-TOCn. Here, your Before Text indents are dramatically increasing with level. It happens that if you have a rather short number and also a short heading (the case of your “batlog” without “redo”), the total length of number+heading is shorter than the Before Text indent. The frequently disregarded point in paragraph styles with negative First line indent is the Before Text indent implicitly defines a tab stop.* In your case, the T in the content entry will cause a stop at this position because it is the first tab stop available. It has no leader associated with it. The right margin stop is the second one but is not used.

Unless you anticipate to have 2-line or multiline headings in your book, there is no need of First Line indent, so that you are not bothered by this implicit tab stop. Or alternatively, define a tab between E# and E to align all headings independently from their numbers.

  • Last, your twiddling for header/footer. You put a heavy stress on Writer but using a variable definition, only to capture the last heading in a page. It complicates editing of your headings, while you have a handy built-in feature.

    Type your headings as ordinary text. Headings automatically define bookmarks. This means they can be used to insert cross-references. Your apparent goal is to echo in the footer the last heading in the page. For that, instead of a field referencing your heading user-variable, insert a field from Document, type Chapter, format Chapter name or Chapter number and name if you want both. The trick is to set level to the highest level you want to echo, e.g. 4. If the last heading has a shallower level than the one specified, the shallower will be used. For example, in you sample file, the second page contains only a level-2 heading. I set level to 4, so that the first page displays 1.1.2 batlog and the second one 1.2 Introduction. No need for a user-variable nor the trouble with it!

  • Similarly, instead of defining variables for versioning (CCI_Name and CCI_Version?) your document, use File>Properties, Custom Properties. You can define there document-wide symbols which you can insert as fields from DocInformation. It is really easier to maintain and edit.

As you see, it is only a matter of editing a bit your styles and general document architecture. Be patient and read carefully the user manual to discover all the nice features included with Writer.

To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!