No entries for Bibliography and appendix sections in TOC #954
Applies to conversion with LaTeXML 0.8.2.
The text was updated successfully, but these errors were encountered:
Digging a little, this bug should be fixed after the
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:
Running pdflatex on the minimal example produces the ToC with the appendix and bibliography included, so that is indeed the expected behavior.
Ok, the inaccuracy is in emulating tex's behavior when hiding the
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 -
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
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
The new Tags code doesn't fix it, but may affect (hopefulily simplify) the way to fix it.
So, neither the presence or lack of the old refnum attributes, nor the presence or lack of certain
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
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
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