Re: Bug#338046: whizzytex: FTBFS: einitex not provided anymore by tetex-bin (or elsewhere in sid)
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
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Reply to: