August 2003 - ntg-pdftex - NTG Mailing Lists

Re: Problem with latest pdfTeX 1.11a release?
by Martin Schroeder 11 Aug '03

11 Aug '03

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 <v3.7h> 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(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

7 10

Re: [NTG-pdftex] Re: Problem with latest pdfTeX 1.11a release?
by Hans Hagen 11 Aug '03

11 Aug '03

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(a)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 -------------------------------------------------------------------------

2 5

Patch CreationDate
by Heiko Oberdiek 11 Aug '03

11 Aug '03

Hello, Patch CreationDate If /CreationDate is not given by \pdfinfo, then a default is used by computing the string by the current setting of \year, \month, and \time. Problem A: The time zone is not set. See the discussion in de.comp.text.tex, "[pdftex] Zeitzone von CreationDate" Valentin Schwamberger observed that his AR/Windows shows then the time as GMT. Problem B: It is easy to fool pdfTeX: * Setting \year to a number less or greater than 4 digits. * Setting \year, \month, \date, \time to invalid numbers, eg.: \month=13 The result are invalid dates. The following patch tries to solve these problems: * Time zone detection by glibc's strftime("%z"). * The current time is used, not \year, \month, ... Patch files based on 2003/07/30 v1.11a: utils.c.diff for TeX/texk/web2c/pdftexdir/utils.c pdftex.ch.diff for TeX/texk/web2c/pdftexdir/pdftex.ch pdftex.defines.diff for TeX/texk/web2c/pdftexdir/pdftex.defines Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

3 19

freshmeat
by Martin Schroeder 06 Aug '03

06 Aug '03

Hi, I've submitted a project description of pdfTeX to freshmeat (http://freshmeat.net/) as http://freshmeat.net/projects/pdftex/ Will keep you informed. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

1 1

pdftexbin
by Martin Schroeder 05 Aug '03

05 Aug '03

pdftexdir/pdftex.mk has these lines: <blockquote> # pdftex binaries archive pdftexbin: rm -f pdtex*.zip $(pdftex_bin) XLDFLAGS=-static $(MAKE) $(pdftex_bin) if test "x$(CC)" = "xdos-gcc"; then \ $(MAKE) pdftexbin-djgpp; \ elif test "x$(CC)" = "xi386-mingw32-gcc"; then \ $(MAKE) pdftexbin-mingw32; \ elif test "x$(CC)" = "xgnuwin32gcc"; then \ $(MAKE) pdftexbin-gnuwin32; \ else \ $(MAKE) pdftexbin-native; \ fi pdftexbin-native: strip $(pdftex_bin) zip pdftex-native-`datestr`.zip $(pdftex_bin) $(pdftex_pool) pdftexbin-djgpp: dos-strip $(pdftex_bin) dos-stubify $(pdftex_bin) zip pdftex-djgpp-`datestr`.zip $(pdftex_exe) $(pdftex_pool) pdftexbin-mingw32: i386-mingw32-strip $(pdftex_bin) for f in $(pdftex_bin); do mv $$f $$f.exe; done zip pdftex-mingw32-`datestr`.zip $(pdftex_exe) $(pdftex_pool) pdftexbin-gnuwin32: gnuwin32strip $(pdftex_bin) for f in $(pdftex_bin); do mv $$f $$f.exe; done zip pdftex-gnuwin32-`datestr`.zip $(pdftex_exe) $(pdftex_pool) </blockquote> It's clear what these lines should do, but unfortunately they currently don't work: - the binaries made are _very_ static: they don't work. We make static linux binaries by setting LDFLAGS=-static before configure... - datestr is undefined. - I can't test non-native plattforms, so I don't know if they still work Can this be fixed or should the targets go? Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

2 1

reserveobjnum (was: release notes for pdfTeX 1.11a (draft))
by Martin Schroeder 01 Aug '03

01 Aug '03

On 2003-07-30 18:56:42 +0200, Hans Hagen wrote: > At 16:58 30/07/2003 +0200, Martin Schroeder wrote: > > >- The syntax of \pdfobj has been extended: > > \pdfobj <object type spec> (h, v, m) > > <object type spec> --> reserveobjnum > > | [useobjnum <number>] [<attr spec>] [stream > >[<attr spec>]] <object contents> > > <object contents> --> <file spec> > > | <general text> > > When the optional keyword `reserveobjnum' and `useobjnum' is not given, > > the behaviour is unchanged. > > what is <number> in reserveobj, any number? how is the user supposed to > know which numbers are free? > > \pdfobj reserveobjnum 123 {} > \pdfobj useobjnum 123 {} > > do both flush content? what if 123 is already taken? That's wrong; it must be \pdfobj reserveobjnum {} \pdfobj useobjnum \pdflastobj {} See also http://tug.org/mailman/htdig/pdftex/2003-March/003814.html <blockquote src=pdftex.ch> @ The \.{\\pdfobj} primitive is to create a ``raw'' object in PDF output file. The object contents will be hold in memory and will be written out only when the object je referenced by \.{\\pdfrefobj}. When \.{\\pdfobj} is used with \.{\\immediate}, the object contents will be written out immediately. Object referenced in current page are appended into |pdf_obj_list|. </blockquote> Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

1 0