# [tex-live] Re: [NTG-pdftex] Re: Problem with latest pdfTeX 1.11a release?

Hans Hagen pragma at wxs.nl
Fri Aug 8 10:21:53 CEST 2003

```At 08:26 08/08/2003 +0200, Staszek Wawrykiewicz wrote:
>On Thu, 7 Aug 2003, Thomas Esser wrote:
>
> > I'd prefer a solution wich is better than n*m entries in texmf.cnf (n =
> > number of formats, m = number of tex engines).
> >
> > Solution a)
> >
> >   (does not really solve the n*m problem, but provides a good
> >   default-TEXINPUTS and has other advantages):
> >
> >   ENGINE variable, set by each engine, but with different values (not
> >   depending on progname, but on the real engine). It could have the
> >   following values (examples):
> >
> >       engine       \$ENGINE
> >       ==============================
> >       pdfetex      {pdftex,etex,tex}
> >       etex         {etex,tex}
> >       eomega       {omega,etex,tex}
> >
> >   If every engine defines that \$ENGINE, than we could have e.g.
> >     TEXINPUTS = .;\$TEXMF/\$ENGINE/{generic,}//
> >     TEXINPUTS.latex = .;\$TEXMF/\$ENGINE/{latex,generic,}//
> >
> >   This solution also takes care of "behind the scene" changes, e.g.
> >   if latex switches from tex to etex as engine.
> >
> > Solution b)
> >   Drop all texmf/pdftex, texmf/pdfetex, texmf/omega, ... things in
> >   favor of texmf/tex. History has shown that most macro packages
> >   which are not written for "tex", but for some other engine
> >   already detect the engine. There are only very few conflicts
> >   between these trees, one is e.g. webmac.tex, but that can easily
> >   be fixed by replacing tex/plain/base/webmac.tex with a wrapper
> >   which first detects the engine and then ready either the "real"
> >   webmac.tex or pdfwebmac.tex.
> >
> > b) should be discussed on the TDS list if other people share my opinion.
> > BTW: my favorite solution is b).
> >
> > Thomas
>
>Great idea! I'd vote for b) and suggest it for TL 2003

sounds ok to me, but why not also implement \$ENGINE as variable to be set
by the engine (one never knows when this will come in handy)

another related problem:

-  pdftex differs from dvips which is why the texmf/pdftex path cannot go
-  pdftex.cfg is now common for all macropackages, while i would like a
package dependent one

with regards to the cfg file: context has one format that deals with dvi
and pdf output; therefore i don't like the idea that pdf output is
hardcoded in the cfg file; (ok, i can handle it at the macro level)

since pdftex is 100% dvi compatible, why is there still latex/pdflatex,
tex/pdftex, etc ; we could have much less formats (and generation) when the
relevant macro packages should simply set \pdfoutput=1 which they have to
do anyway; users have to load pdf specific functionality and that is the
moment the macro package can set the flag; removing the dupplication would
also make it more easy to explain to users what is going on.

currently there is no control from within the macro package where files are
looked for, apart from hard coded paths . .. and combinations; maybe the
core file handler can be extended so that we can say things like

\input {\$texmf-local,\$texmf}/somefile

or \input [::texmf-local,::texmf]/somefile if we want to get rid of
potential clashes with catcodes

Hans

Hans
-------------------------------------------------------------------------
Hans Hagen | PRAGMA ADE | pragma at wxs.nl
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------