0

I'm using the latest texlive to compile tex file into HTML:

$ apt show texlive
Package: texlive
Version: 2021.20220204-1
Priority: optional
Section: universe/tex
Source: texlive-base
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian TeX Task Force <debian-tex-maint@lists.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 73.7 kB
Depends: texlive-fonts-recommended (>= 2021.20210921), texlive-latex-base (>= 2021.20210921), texlive-latex-recommended (>= 2021.20210921)
Homepage: http://www.tug.org/texlive/
Download-Size: 14.3 kB
APT-Sources: http://apt.pop-os.org/ubuntu jammy/universe amd64 Packages

When I invoke htlatex tool to do this, I found 2 problems:

  1. htlatex should compiles into hypertext, and use tex4ht as the backend compiler. But when I execute it:
$ htlatex -synctex=1 -file-line-error -interaction=nonstopmode -output-directory=/home/peng/git-slide/oricep_support_and_actuation/out /home/peng/git-slide/oricep_support_and_actuation/doc/tex/Main.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian) (preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(/home/peng/git-slide/oricep_support_and_actuation/doc/tex/Main.tex

...


Output written on Main.dvi (6 pages, 21096 bytes).

This behaviour seems to be deliberately broken, as pdfTex should be the backend of pdflatex, and is only intended to generate pdf and dvi, it is completely irrelevant to hypertext.

  1. The "-output-directory" part appears to be ignored, as even the generated dvi file is dropped into the same directory as the text file

Is the tool htlatex always broken like this? What are the possible successors?

tribbloid
  • 113
  • 1
    htlatex is a shell script that runs latex (which these days is pdftex running in dvi/latex mode) and then runs tex4ht/t4ht afterwards. Moreover, htlatex does not take the same arguments as pdf/latex. The argument -synctex=1 makes no sense in this context, and the others are at best misplaced; see here. The closest thing to a successor is probably make4ht. – frabjous Sep 06 '22 at 00:33
  • thanks a lot, just tried make4ht, it is also kind of malfunctioning but appears to be better, will post a new question for make4ht – tribbloid Sep 06 '22 at 00:47
  • the behaviour your explained is still wrong, tex4ht/t4ht should also be irrelevant to pdftex. – tribbloid Sep 06 '22 at 00:49
  • New question posted: https://tex.stackexchange.com/questions/656320/when-compiling-with-make4ht-how-to-avoid-generation-of-intermediate-files-that – tribbloid Sep 06 '22 at 00:59
  • 2
    pdftex is not irrelevant to htlatex. Read the overview of how htlatex works. Simplifying, first it builds a special .dvi with the standard TeX engine, and then tex4ht then uses this .dvi when creating the html. PdfTeX running in dvi mode provides the standard TeX engine on recent TeX distributions, so htlatex uses the pdftex binary. It's actually a coincidence that with the order of your arguments the script didn't choke when making these calls to the pdftex binary, but only later. – frabjous Sep 06 '22 at 01:01
  • 1
    Definitely related: Convert LaTeX to HTML. – Teepeemm Sep 06 '22 at 01:19
  • 1
    why do you think this behaviour is broken? it has always been a fundamental part of the conversion to html that tex4ht runs latex. htlatex and make4ht are build scripts using the same underlying converter – David Carlisle Sep 06 '22 at 06:30

0 Answers0