[pdftex] texi2dvi does not generate dvi on Debian Etch and MacOS X
karl at freefriends.org
Tue Jul 31 01:17:55 CEST 2007
Thanks for writing, but I'm afraid you won't like my answer.
The reason seems to be that texi2dvi calls etex,
Not a bug.
and etex looks as follows on this system:
lrwxrwxrwx 1 root root 7 Apr 10 11:48 /usr/bin/etex -> pdfetex*
Also not a bug.
Now maybe this is a configuration error on Debian,
I believe so. etex should produce .dvi by default (whatever its binary).
What matters, in the end, is the value of \pdfoutput at the time the
.fmt was dumped. Find the fmtutil.cnf file on your system, look at the
etex line. On my system (TeX Live 207), it looks like this:
etex pdftex language.def -translate-file=cp227.tcx *etex.ini
And etex.ini just reads etex.src and does \dump, so \pdfoutput=0, so the
output is dvi by default. The pdf[e]tex.ini files, in contrast, set
\pdfoutput=1 (among other parameters), so the output is pdf by default.
[c8:/raid0/anton/tmp/gforth/doc:9692] etex -output-format dvi gforth.texi
Now that is strange. I would have thought the cmdline option would
override anything in the .fmt. For me, it does (pdfTeXk, Version
3.141592-1.40.3 (Web2C 7.5.6)). Maybe it was a bug in pdftex itself
that got fixed between your version and mine; maybe it is a difference
introduced by Debian (the canonical pdftex does not use poppler, for
instance). I don't know.
system (it calls tex, not etex).
So, if you want a workaround, you can setenv TEX=tex for texi2dvi. It
is highly desirable to call etex if it is present, so I don't want to
change the default. Checking for broken TeX configurations seems
basically impossible; I really wouldn't like to go down that road.
Hope this helps somehow,
More information about the pdftex