Michal, Thank you for diagnosing this! It's no problem at all to make the change, and I've done so to the MWE that I sent you on this mail thread. In any case, htlatex is very fast (compared to lulatex,so the multiple runs are inconsequential). This is a little long, and I hope it's all clear.
While you were diagnosing this issue, I had already found the next bug. At the end is (what I think is) a very, very simple example that shows that indexes are just broken, along with several other errors. Because it's getting a little difficult to know precisely what MWE is being discussed, which config files, etc, I took the liberty of setting up a little GIT repo to store them in. If this isn't a good way to communicate examples to you, please let me know, and I'll return to just attaching files to emails. But absent your contra-indication, for the moment I'll store each MWE in a separate directory, self-contained, with a Makefile to run all build-steps for definiteness. That was the only reason I put the "clean" step in there: to ensure that there were no files left-over from previous runs, to pollute later runs. BTW, I've also updated my Texlive installation using "tlmgr update --all". I don't know how to get a version-number or timestamp from Texlive, so I can't identify the exact version of all the Texlive software I'm using. So I'll just ensure that each time, I report when I updated with tlmgr. The repo is here: https://github.com/chetmurthy/latex-mwes OK, those preliminaries aside, (0) Updated Texlive: just before this email ==THIS WORKS, JUST DOCUMENTING IT================= (1) the MWE I sent you on Feb 25 (in this thread), and then with the updated build instruction per your email of Feb 27, is here: https://github.com/chetmurthy/latex-mwes/tree/master/mwe-1/2025-02-25-12-58 To reproduce: $ make sample.FULL And that falis (b/c it runs htlatex only once) with 5 "Fragment identifier is not defined" errors from epubcheck (v5.2.1) ==THESE ALL FAIL================= (1') with your updated build.lua, in the directory https://github.com/chetmurthy/latex-mwes/tree/master/mwe-1/2025-03-04-05-00 the sample now works and no errors are reported by epubcheck. To reproduce: $ make sample.FULL =================== (2) but meanwhile, I made an even simpler MWE, with a single chapter, a single \index entry: https://github.com/chetmurthy/latex-mwes/tree/master/mwe-2/2025-03-04-05%3A00 This yields (with the updated build.lua file) 1 "Fragment identifier is not defined". To reproduce: $ make sample.FULL Looking at the generated HTML, it seems that both the TOC entry for the Index, and the single index-entry, assume that they're part of the same file. The fragment-ids are correct, but are in the wrong files. ========================= (2b) sample.ind is overwritten by tex4ebook, and that new version is not accepted by lualatex But also, I found that the "sample.ind" file that was generated by "makeindex" after lualatex, got overwritten by the htlatex runs, and when lualatex was run after it, (without "make clean"), lualatex fails with error: [4] (./sample.ind ! Undefined control sequence. l.5 \item bool (type), {\Link []{x3-2001}{}1\EndLink{}} ? To reproduce: $ make sample.IND-FILE-BROKEN =================== (2c) generated HTML is -badly- malformed There's a package included, \usepackage[most]{tcolorbox} that is entirely superfluous. If you comment this out, then the generated sample.html is malformed, viz. FATAL(RSC-016): sample.epub/OEBPS/sample.html(3,3): Fatal Error while parsing file: Comment must start with "<!--". and this is caused by an element being emitted -before- xmldecl (which is completely malformed). (2d) Last, I got stack-overflow when processing my entire book, but I have not tried to isolate that, since these errors are so much more basic On Tue, Mar 4, 2025 at 2:42 AM Michal Hoftich <michal....@gmail.com> wrote: > Hi Chet, > > I've found that the problem is caused by the Makefile always removing all > temporary files. TeX4ht needs several runs to get links right and store > some information in the temporary files. So there are two possible fixes: > > 1. don't remove the temp files every time, only when necessary (using > explicit "make clean" rule) > 2. execute Make:htlatex {} multiple times after index generation: > > Make:htlatex {} > Make:xindex {} > Make:htlatex {} > Make:htlatex {} > Make:htlatex {} > > This can make the compilation significantly slower, but it will always > work with the cleanup of temp files. > > Best regards, > Michal > > On Fri, Feb 28, 2025 at 2:22 AM Chet Murthy <murthy.c...@gmail.com> wrote: > >> Michal, >> >> The latest file doesn't change the outcome of the run. At this point, we >> have 4 files: build.lua, config.cfg, index.4ht, listings.4ht. And then, to >> keep track of the command, there's a Makefile, and the actual sample.tex. >> >> Do you think it would be useful if I created a little Github repo, and >> sent you pointers to branches in that repo, instead of sending attachments? >> >> For now, I'll continue to send attachments. This time, I'm attaching a >> zipfile: hope that's OK. >> >> When I run the commands to build and then check: >> >> $ tex4ebook -c config.cfg -e build.lua sample.tex >> $ java -jar ../jcf*/tools/epubcheck/epubcheck-5.2.1.jar sample.epub >> >> I no longer get the "duplicate id" errors, but I still get the "fragment >> id not defined" errors: >> ==== >> ERROR(RSC-012): sample.epub/OEBPS/sample.ncx(25,46): Fragment identifier >> is not defined. >> ERROR(RSC-012): sample.epub/OEBPS/sample.html(11,78): Fragment identifier >> is not defined. >> ERROR(RSC-012): sample.epub/OEBPS/sample.html(11,160): Fragment >> identifier is not defined. >> ERROR(RSC-012): sample.epub/OEBPS/sample.html(11,256): Fragment >> identifier is not defined. >> ERROR(RSC-012): sample.epub/OEBPS/samplech1.html(16,50): Fragment >> identifier is not defined. >> ==== >> >> and looking at the unpacked EPUB, I can see that the fragment-id >> ("fn1x1"), referenced in file samplech1.html, exists in file sample3.html. >> So the problem was that the reference was of the form <a href='#fn1x1' -- >> instead of including the filename. >> >> Your advice appreciated, >> --chet-- >> >>
