Hi, > > whizzytex users reported that tetex no longer etex. > > I've not quite investigated the problem; but I would like > > to check the intention. > > > > Is the intention to remove 'etex' 'einitex' commands? > > > > From the 'NEWS' file, it looks like 'pdfetex' is the default now, > > so invoking pdfeinitex would be the right option? > > Atsuhito has already answered the main points. I've just had a look at > the whizzytex sources, and I found some other possible problems.
First: initex is a well-documented interface to running tex for dumping formats. (e.g. 'TeX by Topic'). Please do not deprecate such interface. > First of all, I wonder when initex (or now, pdftex -ini) is used at > all. Usually formats should be generated in the postinst script, and > they should be defined by fmtutil.cnf snippets in /etc/texmf/fmt.d/. > This way it is guaranteed that, if there are changes in tetex-* that > require all formats to be rebuilt, this will be done in tetex-bin's > postinst. TeX source provided by user is processed by initex, and dumped, so that consecutive formatting is speeded up. With whizzytex the whole document is scanned/dumped using initex, and then a slice (a partial portion, divided by \section{} or something convenient) of document is processed at a time for real-time previewing. > Second, whizzytex hardcodes the extension for the format that is > generated. No, it doesn't hardcode, that's why it survived Debian sarge, where tetex generated 'efmt' and platex generated 'fmt'. > However, this is subject to change, too; and if you use the > fmtutil.cnf mechanism, you need not specify it. fmtutil.cnf mechanism is probably irrelevant, since we're not talking about classfiles or style files. We're talking about dumping of TeX internal structures and speeding up processing of TeX. It's real-time, and timing-critical. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]