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@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 -------------------------------------------------------------------------