Re: Problem with latest pdfTeX 1.11a release?
On 2003-08-05 09:35:43 +0200, Gerben Wierda wrote:
Problem
running `pdfetex -ini -jobname=pdfxmltex -progname=pdfxmltex &pdflatex pdfxmltex.ini' ... This is pdfeTeX, Version 3.141592-1.11a-2.1 (Web2C 7.5.2) (INITEX) entering extended mode (/usr/local/teTeX/share/texmf.local/tex/xmltex/config/pdfxmltex.ini Error: pdfetex (file pdftex.cfg): cannot open config file ==> Fatal error occurred, the output PDF file is not finished!
Compare with a recent source.development binaries (everything else is the same)
running `pdfetex -ini -jobname=pdfxmltex -progname=pdfxmltex &pdflatex pdfxmltex.ini' ... This is pdfeTeX, Version 3.141592-1.11a-beta-20030718-2.1 (Web2C 7.5.2) (INITEX) entering extended mode (/usr/local/teTeX/share/texmf.local/tex/xmltex/config/pdfxmltex.ini LaTeX2e <2001/06/01> Babel
and hyphenation patterns for american, british, french, german, n german, dutch, nohyphenation, loaded. (/usr/local/teTeX/share/texmf.local/tex/xmltex/base/xmltex.tex xmltex version: 2002/06/25 v1.9 (Exp) Looks like a possible problem in pdftex to me. Ordinary TeX ini works well in both cases.
Looks like a case of http://tug.org/pipermail/tex-live/2003-August/003974.html Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
On Tue, 5 Aug 2003, Martin Schroeder wrote:
On 2003-08-05 09:35:43 +0200, Gerben Wierda wrote:
Problem
running `pdfetex -ini -jobname=pdfxmltex -progname=pdfxmltex &pdflatex pdfxmltex.ini' ... Error: pdfetex (file pdftex.cfg): cannot open config file ==> Fatal error occurred, the output PDF file is not finished!
Looks like a case of http://tug.org/pipermail/tex-live/2003-August/003974.html
Now that all the pdf* -ini versions want to read pdftex.cfg, they require also an entry line in texmf.cfg to find it, e. g.: TEXINPUTS.pdfinitex = .;$TEXMF/{pdftex,tex}/{plain,generic,}// for pdftex -ini. Maybe in the case above it's more something like TEXINPUTS.pdfxmltex = ... Greetings Hartmut ------------------------------------------------------------------------ Hartmut Henkel, Oftersheim, Germany ------------------------------------------------------------------------
On Wed, 6 Aug 2003, i wrote:
Now that all the pdf* -ini versions want to read pdftex.cfg, they require also an entry line in texmf.cfg to find it, e. g.:
TEXINPUTS.pdfinitex = .;$TEXMF/{pdftex,tex}/{plain,generic,}//
for pdftex -ini.
This is a little bit different, sorry: Which line from texmf.cfg is used, depends on the variable kpse_program_name, which is set right after program start. Call kpse_program_name -------------------------------------------- pdftex pdftex pdftex -ini pdftex pdfinitex pdfinitex pdftex -progname=pdfinitex pdfinitex So pdftex -ini interprets TEXINPUTS.pdftex, whereas pdfinitex wants a line TEXINPUTS.pdfinitex. This differs from to the non-pdf tex versions, where tex and initex both look into the same line, TEXINPUTS.tex. Now one could... * strip the ini part from kpse_program_name, so that all pdftex and pdfinitex look to the same line in texmf.cnf (as with tex/initex), it would still be the ini version due to the iniversion variable; or * expand program names pdf*tex in the -ini case to pdf*initex, then pdftex -ini and pdfinitex would behave the same. But extra entry lines in texmf.cnf would be required; or * leave as is and be happy with additional texmf.cnf entries, which should then be identical for pdftex and pdfinitex, to avoid surprises. Greetings Hartmut ------------------------------------------------------------------------ Hartmut Henkel Oftersheim, Germany ------------------------------------------------------------------------
On 2003-08-06 23:11:19 +0200, Hartmut Henkel wrote:
So pdftex -ini interprets TEXINPUTS.pdftex, whereas pdfinitex wants a line TEXINPUTS.pdfinitex. This differs from to the non-pdf tex versions, where tex and initex both look into the same line, TEXINPUTS.tex.
Why? Just because pdfTeX reads a config file and TeX doesn't? [...]
* leave as is and be happy with additional texmf.cnf entries, which should then be identical for pdftex and pdfinitex, to avoid surprises.
I favour this. :-) Of course this needs to be documented somewhere... Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
On 2003-08-07 00:28:29 +0200, Martin Schröder wrote:
On 2003-08-06 23:11:19 +0200, Hartmut Henkel wrote:
* leave as is and be happy with additional texmf.cnf entries, which should then be identical for pdftex and pdfinitex, to avoid surprises.
I favour this. :-)
Whatever happens has to be decided by the distribution maintainers. Thomas, Olaf, Fabrice, Sebastian -- what's your decision? Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
Whatever happens has to be decided by the distribution maintainers.
Thomas, Olaf, Fabrice, Sebastian -- what's your decision?
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
... 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).
so is mine Thanh
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 -- Staszek Wawrykiewicz StaW@gust.org.pl
I'm with Thomas. The TeX world is small enough that we can avoid the problem by simply insisting on unique names. Sebastian
On Wed, 6 Aug 2003, i wrote:
where tex and initex both look into the same line, TEXINPUTS.tex.
...which is again wrong :-( Slowly getting it, sorry. Hope this is now right: In the teTeX distributed texmf.cnf file, the parsing is as follows: * tex reads line TEXINPUTS.tex. * tex -ini reads line TEXINPUTS.tex. * initex doesn't find a match and reads the catch-all (!), TEXINPUTS, which is fine for initex. * pdftex reads line TEXINPUTS.pdftex. * pdftex -ini reads line TEXINPUTS.pdftex. * pdfinitex finds no direct match, so it tries the last resort TEXINPUTS, where it doesn't find pdf-related entries. Same with pdfeinitex and mptodf, which runs on pdfetex. One can try to see what happens if one simply sets the last TEXINPUTS = "" and comments out most or all of the TEXINPUTS.* lines. So there is less magic than i guessed. Then the simplest solution might be to add lines with TEXINPUTS.pdfinitex, .pdfeinitex, and even .initex, to give initex a real target line other than the catch-all. And a line .mptopdf (similar to .pdfetex) would be needed. Greetings Hartmut ------------------------------------------------------------------------ Hartmut Henkel, Oftersheim, Germany ------------------------------------------------------------------------
Hartmut Henkel writes:
On Wed, 6 Aug 2003, i wrote:
where tex and initex both look into the same line, TEXINPUTS.tex.
...which is again wrong :-( Slowly getting it, sorry. Hope this is now right: In the teTeX distributed texmf.cnf file, the parsing is as follows:
* tex reads line TEXINPUTS.tex. * tex -ini reads line TEXINPUTS.tex. * initex doesn't find a match and reads the catch-all (!), TEXINPUTS, which is fine for initex. * pdftex reads line TEXINPUTS.pdftex. * pdftex -ini reads line TEXINPUTS.pdftex. * pdfinitex finds no direct match, so it tries the last resort TEXINPUTS, where it doesn't find pdf-related entries. Same with pdfeinitex and mptodf, which runs on pdfetex.
This sounds about right. The problem originates in us having both "formats" and "engines". Files specific to a format can be found in places like "texmf/tex/<format>", for example "texmf/tex/latex" and "texmf/tex/latex209". For engines, the "tex" part in "texmf/tex/..." is replaced with the engine name. So we get, as Thomas pointed out, something like an N*M structure, which does tend to get out of hand... For the purposes of path searches, the 'initex' programs are not treated any differtly from all the others. That is, "initex" is used as the "format-suffix", unless overruled by the command-line options. (Examples of the latter are found in the web2c Makefile.) With pdfelatex, you'd be looking in paths suitable for the pdfetex, pdftex, etex, and tex engines -- and is that the correct order? And for each of these engines, you should look in "texmf/<engine>/latex" first. This is because for historical reasons, there are unavoidable name clashes between latex and latex209 files. This means that if you have a texmf tree with both latex and latex209 in it, then _all_ latex-based formats require that their files are looked for in "texmf/<engine>/latex" _first_. Now you could already simply things if all the engine-specific trees are merged into the "texmf/tex" tree. It should not be too hard to keep those files apart even in the single tree, and avoid duplicates. Then the "texmf/tex/latex" subtree is for "latex" regardless of the underlying engine. (And "texmf/tex/pdfelatex" could be specific for the pdfelatex format, which just happens to be specific to a single engine.) Just pushing some nonrandom thoughts... -- Olaf Weber (This space left blank for technical reasons.)
participants (7)
-
Hartmut Henkel -
Martin Schroeder -
Olaf Weber -
Sebastian Rahtz -
Staszek Wawrykiewicz -
The Thanh Han -
Thomas Esser