Custom TOC using \ms fields: How to reduce the number of columns displayed?

Question

I'm typesetting a single-book Genesis publication. We want to display 7 "Major Section" labels in the TOC, and the solution discussed here works, mostly. 

https://support.bible/11592/toc-for-bible-modules

However, the TOC generated by PTXPrint insists on displaying empty columns for \toc2 and \toc3.

The green square in my screenshot shows my manually entered TOC lines as I want them (but with an empty page number column). Above this is the TOC generated by PTXPrint. The first line contains the entries for Genesis: toc1 "full name" toc 2 "short name" toc3 "abbreviation". I do not want this line in my TOC.

The Major Sections  appear correctly, but they wrap poorly because of the missing toc2 and toc3 fields under each section. I want to get rid of the leaders in the red box, displaying just toc1 and page# columns. I have tried 

• deleting the \toc* lines in GEN 1:0, but PT is too smart for me–it keeps re-inserting them. 
• deleting the Scripture Reference List entries, but they keep popping back in both the List and in line one of the generated TOC.
• I entered just a full-stop in the Scr.Ref.List for each of the GEN entries, but the names still pop up in the TOC. 
• I created a new project and imported GEN into it after deleting the toc entries. Somehow PT carried those pesky book name entries along into the new project!

I did, at one stage, duplicate \mr references for each section into \toc2 lines (as in my mock-up table), but this didn't help so I moved the references manually into the \ms+\toc1 lines.

Any thoughts on how to get rid of empty toc2 and toc3 columns in a generated TOC table, please? Or should I just use my manually entered table in the Front Matter, adding page numbers to it as the final typesetting step?

Answer 1

Just checking whether you have tried the obvious (on the Peripherals tab):

Comments

Oh, sorry, yes! Unticking toc2 and toc3 here makes no difference; all three columns appear as in my screenshot.
I should have also noted that I'm using PTXprint 2.4.13 in Wasta 20.04.

Answer 2

The way I would address this is through the judicious use of changes. First you can delete the \toc2 using a change like:

```

"\\toc2[^\\]+" > ""

```

And then we break up the subentries so that the \toc1 has the description and \toc2 has the reference. Inserting the numbers automatically is beyond the capability changes.txt, unless you hide them in the text somewhere. But what you can do is to insert a few hard spaces at the start of the entry to get it to be indented. So an entry line might look like:

```

\toc1 ~~~Hape ke pokoso per mamang inetelik

\toc2 1\emdash 4:16

```

Then on the peripherals page turn on toc1 and toc2 and turn off toc3.

You won't be able to do anything useful in sorting. But you can use the main toc.

It's up to you if you want to turn off the leaders (using the drop down list on the peripherals page)

Comments

Thanks, Martin and Mark! I've just solved the mystery: I found hard-coded \toc* lines in my local Front Matter file! When those are removed the Contents generates correctly (when I leave toc2 and toc3 unticked on the Peripherals page).

Btw, I don't need the numbers column or an indent; I would rather not have wrapped "chapter" titles.  I had entered the trial table into \periph Table of Contents before I learned how to set up the auto-TOC, and I haven't decided whether to delete it yet.

However, now I have another problem: I've compared settings very carefully across two related configurations. I've got the TOC working in "26-JUN-...", but "27-JUN-..." has the font & margins I need, and about 1/3 of the pictures are correctly placed. If I could get the TOC to appear in "27-JUN" like it does in "26-JUN" it'd save me a lot of work. But I can't see why the TOC refuses to generate in the "27-JUN" configuration.

Now, however, I've messed up the TOC in 26-JUN as well, so I'm sending both archives. Please remember that 27-JUN has the settings I want. You can ignore 26-JUN if you can help figure out the better one. Thanks!

---

To clean up this topic for future issues: Is it a bug that if your local Front Matter (in the View/Edit tab) contains hard-coded \toc* fields, then the checkboxes for including the 3 fields are ineffective; the generated TOC includes columns for all of the toc* fields? Those columns should be turn-off-able no matter where their contents are found, right?

---

Not sure why you would want to put \toc entries into front matter. But if you do, you should only put in the entries you want to see. We don't currently remove them automatically based on the periph page settings. Or you can remove the ones you don't want to see using changes.txt.