No entries for Bibliography and appendix sections in TOC

[goska]

Applies to conversion with LaTeXML 0.8.2.
No TOC entries are generated for the Bibliography and sections in the Appendix in the main in-page TOC at the beginning (index.html) of the HTML collection generated from LaTeX using route: LaTeX -> XML, with latexml; XML -> HTML with latexmlpost.
Sidebar navigation is not affected.
Working with report document class and using \addcontentsline{toc}{chapter}{Bibliography} in LaTeX, but I have tried a number of other solutions - none giving the desired outcome.
TOC generation worked OK with LaTeXML 0.8.1 and the same LaTeX document class and structure.

[dginev]

Hi @goska , sorry for the slow reply but could you attach a minimal latex source example for this issue?

[goska]

Sorry - I was away. I'll prepare an example when I get a spare moment (~within a few days).

[goska]

I attached minimal.zip containing two files: minimal.tex and test.bib. Screenshots of index pages generated by LaTeXML 0.8.1 and 0.8.2 transformations (attached) show that TOCs embedded within the main section of index pages differ: the one generated with 0.8.1 includes listing of bibliography and contents of the Appendix, which are missing from the TOC generated with 0.8.2.
I don't know if I made it sufficiently clear that the issue affects not just bibliography, but all chapters/sections of the appendix.
Note that the TOCs in the left navbar are both OK.)
Transformation steps used (I forgot not to include directive --javascript=navigation.js for adding our own script for collapsing TOC in navbar and --stylesheet=xslt/LaTeXML-html5.xsl which loads customized XSLT style sheet (to inject custom wrapper HTML and not affecting TOCs), but both can be safely taken out):
latexml --dest=test.bib.xml test.bib latexml --dest=minimal.xml minimal.tex latexmlpost --dest=../../../tests/minimal_test_8_1_2/index.html --urlstyle=server --navigationtoc=context --javascript=https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.2/MathJax.js?config=MML_HTMLorMML --javascript=navigation.js --stylesheet=xslt/LaTeXML-html5.xsl --splitat=subsection --splitnaming=labelrelative --css=LaTeXML-navbar-left.css --format=html5 minimal.xml

minimal.zip

[dginev]

Thank you for the details, this is now the perfect bug report! Will take a look.

[dginev]

Digging a little, this bug should be fixed after the TagsNTitles work is merged in, since the infrastructure changes there are directly involved in the table of contents scanning and filling.

So, testing with that branch, I can still reproduce the report, and even see an error that isn't showing up on the master branch:

Warning:undefined:UNappendix Counter 'UNappendix' was not defined; assuming 0
	at /home/deyan/Downloads/minimal.tex; line 49 col 44
	In Core::Definition::Constructor[\@@unnu... from LaTeX.pool.ltxml line 518

Error:undefined:\theappendix@ID The token T_CS[\theappendix@ID] is not defined.
	at /home/deyan/Downloads/minimal.tex; line 49 col 44
	Defining it now as <ltx:ERROR/>
	In Core::Stomach[@0x564c992bb878] at /home/deyan/Downloads/minimal.tex; line 49 col 44
	 <= Core::Gullet[@0x564c992bb800] <= Core::Stomach[@0x564c992bb878] <= Core::Definition::Constructor[\@@unnu... <= ...

Running pdflatex on the minimal example produces the ToC with the appendix and bibliography included, so that is indeed the expected behavior.

[dginev]

Ok, the inaccuracy is in emulating tex's behavior when hiding the A tag of an appendix chapter via redefining the depth. In the source:

\setcounter{secnumdepth}{-2}
\appendix

latexml currently completely omits such appendixes from the ToC, while pdflatex adds them without any tag.

The Bibliography line missing from the ToC seems to be a separate issue - \addcontentsline is not yet implemented.

[dginev]

This is where @brucemiller's wisdom is needed. This type of appendix seems to be desired to be indexed, but tag-free. From what I understand so far, the scan for the table of contents metadata relies on tags being present, in order to index a given heading? If so, we may want to deposit empty tags for the unnumbered section types of material.

[brucemiller]

Actually, this is essentially a duplicate of #914. It's not so much a regression, at an attempt to behave more like LaTeX! OTOH, there needs to be a way to get these entries when you want. Perhaps \addcontentsline can figure out what to do, as in LaTeX. The secnumdepth trick is curious: you use \section w/o star, so it should appear in contents, but not numbered.... hmm...

The new Tags code doesn't fix it, but may affect (hopefulily simplify) the way to fix it.

[brucemiller]

So, neither the presence or lack of the old refnum attributes, nor the presence or lack of certain ltx:tags are reliable indicators of whether a given object should appear in the toc. I hate adding a new attribute to (presumably the negative hidetoc), but I'd have to hold my nose to add a fake class! more hmm...

[dginev]

I'm wondering of an alternative approach, which is also some work.

Would if make sense to dynamically modify the table of contents element, the way we do with frontmatter as it is collected, rather than annotate the individual elements inline?

That also makes it a little more direct to implement \addcontentsline I think, since there will be a simple place to put it, and it will be added in the right order. Though of course it can be an invisible element with the current scheme...

[brucemiller]

It would up to a point, but wouldn't scale to multi-document sites. The more I think (& reread LaTeX companion), the more convinced it's worth biting the bullet and add inlist attribute to anything that can get labelled. It could contain toc, lof, lot, etc. With a bit of refactoring Post::CrossRef this would be cleaner and would automatically support more arbitrary "list of frobnitz". Remaking so many tests is tedious, but basically just replaces the new ones in TagsNTitles anyway. (presumably should squash the commits? or does it really matter?)

[dginev]

Cool, sounds like a plan. I don't have a LaTeX book near me to figure out how many types of hoops there are to jump through anyway, just brainstorming.

I would actually suggest branching off from TagsNTitles and merging these changes as a separate PR - that branch is already large enough, and it will be very hard to see what the new changeset would bring in.

As to squashing, it's down to personal preference - depends if you down the line you think it will be more valuable to see this as a single commit in the GitHub diff, or as a stream of separate patches. I'm fine either way, would've squashed it if it was down to me. And then made a separate branch for the inlist refactor.

[brucemiller]

This should be working fine, now. Thanks for the detailed report!