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

[Hans Hagen]

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
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------