Open davidg-sil opened 3 years ago
I am reluctant to build preprocessing layers into the ptx macros if we can avoid it. TeX is a very poor preprocessor and lacks necessary flexibility. To address @mnjames desire for subheadings in his table of contents, there is an incomplete proof of concept (which probably has a way to go) achieved by simply adding:
'\\s (.*?\r?\n)' > '\\s \1\\toc1 \1'
to the PrintDraftChanges.txt which adds the subheading as a toc1 entry. Of course then there is the question of how to lay out such a multi-level table.
But looking at this, perhaps what is more desirable is some kind of page reference scheme whereby an anchor can be dropped in the USFM and then reference made to that anchor to insert its page numbers, complete with forward referencing. Then FRT matter or anything can reference page numbers as well as references. So for example, the \io1 type outline could include page numbers if that would help. Perhaps use the .notepages file for this (to save yet more aux files), with a different macro.
Adding \toc1 markers (such as the regex @mhosken suggested) was one of my first thoughts. And simply adding that regex works fine and doesn't cause any problems. But as soon as I think turn on the "Table of Contents" checkbox the printjob fails. I've attached a log of what I get when it fails. ptxprint-Hz_Musa_2021-XXBLNG.log
I'm not sure what 'preprocessing' you're thinking of @mhosken. I think I was assuming that the milestone would write
\tocline{text}{page}
To the relevant files, and the \zincludelists
call would read that file and turn it into \tr\tc1
... lines.
I guess I'm also assuming that the list is purely in occurrence order... were thinking of a (re)sorted list, when you speak of preprocessing?
I'm not sure why \toc1 markers weren't working for me before. They are now. So I can create a ToC based on a regex changing \s tags to \toc1. So from my point of view this is fixed (though the enhancement that @davidg-sil of incorporating this closer into the PTXprint program instead of having it rely on regex changes added to the printdraftchangest.txt file would be easier).
As to the original request in this issue. I would be OK with beefing up and adding a layer to the current \doTOCline to add a toc category. Thus we could have \doTOCline{TOC}{ref}{tocA}{tocB}{tocC}{tocD=\pageno} and so on. Then we get ptxprint to pull the main apart into different TOCs and then we can reference them in the appropriate file.
I think it would be best to keep all the TOC stuff in one file rather than yet more proliferation of auxiliary files. So, here's what I'm proposing. The \t@cfilename generates a file with \defTOC{global}{ and then each line has a \doTOCcategory{type}{sortkey/reference}{ncols}{colA}{colB}...{colncols-1}
Then ptxprint processes that file to split out everything from the global \defTOC to produce lists of \defTOC{illustrations}{ with \doTOCline{sort/ref}{ncols}{colA}{colB}...
Then the appropriate \ztoc|illustrations* can generate the appropriate table in the peripheral or wherever.
This raises the question what the category that the table uses. Currently it's fixed to toc
. Do we really want it to be toca
or illustrations
?
We also need to add capabilities for such toc entries to be added in the text. The issue here is that you can't pass parameters (no { }) in USFM text. I suppose would give a milestone for it. \ztocentry|type="illustrations" ref="sortkey" colA="columnA text" colB="colB text" colC="colC"* which we could hard wire the columns or add a parameter for the column count. Not sure how to express an array. The fun of turning \count (e.g. 3) with catcode 12 to catcode 11 which is what it is inside USFM. But that's doable. OK so:
\ztocline|type="maps" key="sortkey" cols="3" col1="Column 1 text" col2="Col2 text" col3="3text"\*
and you get one extra column on the end with the pagenumber. keys are interpretted as scripture references and if that fails as strings. Woe betide you if you mix key types in a given TOC type.
I think there may (eventually or next week, given this query) be a demand for some kind of generic list-of-X handling code, where X might be figures, tables, articles in sidebars, maps, etc. I'm not aware of us having anything that does that (though the information is available for figures). Perhaps some kind of markup like these:
Where
\zlistentry
might write the title, pageno entries to a generic or book-specific file. e.g.list-maps-BOOK.lst
And then maybe:
Which would open the file and put it into an appropriately categorised table.