\pdfinfo used while \pdfoutput is not set

59 views
Skip to first unread message

Michael Ströder

unread,
May 30, 2005, 2:22:14 AM5/30/05
to
HI!

I'm documenting a Python module using some latex(?) templates/modules
shipped with the Python 2.4.1 source distribution. This used to work for
quite some while until last update of my SuSE Linux. The packages
installed are:

tetex-3.0-13
te_latex-3.0-13
latex2html-2002.2.1-366
latex2html-pngicons-2002.2.1-366
latex-ucs-20040703-3

I found some FAQ on http://www.tex.ac.uk/cgi-bin/texfaq2html?label=ifpdf
explaining the problem but since I'm a real tex illiterate I have no
clue how to add that workaround to my own docs. How can I include this
code in my docs?

You can sneak the source of the docs here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Doc/

I'll be really glad to get some advice. Thanks in advance.

Ciao, Michael.

------------------------------------------------------------------------
+++ latex python-ldap
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(/home/michael/Proj/python-ldap/python-ldap/Doc/python-ldap.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/home/michael/src/Python-2.4.1/Doc/texinputs/manual.cls
Document Class: manual 1998/03/03 Document class (Python manual)
(/home/michael/src/Python-2.4.1/Doc/texinputs/pypaper.sty
(/usr/share/texmf/tex/latex/psnfss/times.sty)
Using Times instead of Computer Modern.
) (/usr/share/texmf/tex/latex/fancybox/fancybox.sty
Style option: `fancybox' v1.3 <2000/09/19> (tvz)
) (/usr/share/texmf/tex/latex/base/report.cls
Document Class: report 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/home/michael/src/Python-2.4.1/Doc/texinputs/fancyhdr.sty)
Using fancier footers than usual.
(/home/michael/src/Python-2.4.1/Doc/texinputs/fncychap.sty)
Using fancy chapter headings.
(/home/michael/src/Python-2.4.1/Doc/texinputs/python.sty
(/usr/share/texmf/tex/latex/tools/longtable.sty)
(/usr/share/texmf/tex/latex/tools/verbatim.sty)
(/usr/share/texmf/tex/latex/base/alltt.sty)))
(/home/michael/Proj/python-ldap/python-ldap/Doc/version.tex)
Writing index file python-ldap.idx
(/home/michael/Proj/python-ldap/python-ldap/Doc/python-ldap.aux)
(/usr/share/texmf/tex/latex/psnfss/ot1ptm.fd)
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
<argument> { \def \\{, } \pdfinfo
{ /Author (\@author ) /Title (\@title
) } }
l.19 \maketitle

No pages of output.
Transcript written on python-ldap.log.
*** Session transcript and error messages are in
/home/michael/Proj/python-ldap/python-ldap/Doc/python-ldap.how.
*** Exited with status 1.
make: *** [python-ldap.dvi] Error 1

Heiko Oberdiek

unread,
May 30, 2005, 3:53:22 AM5/30/05
to
Michael Ströder <mic...@stroeder.com> wrote:

> (/home/michael/src/Python-2.4.1/Doc/texinputs/manual.cls

> pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> <argument> { \def \\{, } \pdfinfo
> { /Author (\@author ) /Title (\@title
> ) } }
> l.19 \maketitle

The error is in the python class files manual.cls and howto.cls.

| \@ifundefined{pdfinfo}{}{{
| % This \def is required to deal with multi-line authors; it
| % changes \\ to ', ' (comma-space), making it pass muster for
| % generating document info in the PDF file.


| \def\\{, }
| \pdfinfo{
| /Author (\@author)
| /Title (\@title)
| }
| }}

pdfTeX also can be used to generate DVI. Thus the count of
executables is reduced and pdfTeX is used both for DVI output
and PDF output.

Two solutions:
a)
Add near the beginning of manual.cls and howto.cls:

\RequirePackage{ifpdf}
\newcommand*{\@ifpdftexisnotavailable}{%
\ifpdf
\expandafter\@secondoftwo
\else
\expandafter\@firstoftwo
\fi
}

And replace the test "\@ifundefined{pdfinfo}" by
"\@ifpdftexisnotavailable".

Or
b)
Add near the beginning of manual.cls and howto.cls:

\RequirePackage{ifpdf}

And replace

\@ifundefined{pdfinfo}{}{<...>}

by

\ifpdf
<...>%
\fi

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
May 30, 2005, 5:29:01 AM5/30/05
to
Michael Ströder wrote:
> HI!
>
> I'm documenting a Python module using some latex(?) templates/modules
> shipped with the Python 2.4.1 source distribution. This used to work for
> quite some while until last update of my SuSE Linux.

<snip>

Heiko has explained in another response how to fix the problem.

As I understand it, it is because a recent release of pdftex is not
backwards compatitable.

Please would someone confirm that this is correct?

And if so, also point to where this change is documented?


Michael: Does this problem affect _all_ Python documentation?
Or just the stuff you are authoring?

--
Jonathan


Ralf Stubner

unread,
May 30, 2005, 5:39:42 AM5/30/05
to
Jonathan Fine <jf...@pytex.org> writes:

> As I understand it, it is because a recent release of pdftex is not
> backwards compatitable.

No.

> And if so, also point to where this change is documented?

,----[ TETEXDOC ]
| 4.6 pdfetex: the new default TEX engine
|
| teTEX uses pdfetex for all formats except ``good-old'' tex. So, if you
| run latex, the underlying engine will be pdfetex. Some (broken) TEX
| macros assume that pdfTEX is running in PDF generation mode if they
| detect primitives that pdfTEX has introduced (e.g. \pdfoutput). This is
| wrong, since pdfTEX can also be used (and is used) to gen- erate DVI
| output. A reliable way of detecting PDF output mode is implemented in
| ifpdf.sty which works for plain TEX as well as LATEX.
`----

cheerio
ralf

Heiko Oberdiek

unread,
May 30, 2005, 5:51:43 AM5/30/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Michael Ströder wrote:
> > HI!
> >
> > I'm documenting a Python module using some latex(?) templates/modules
> > shipped with the Python 2.4.1 source distribution. This used to work for
> > quite some while until last update of my SuSE Linux.
>
> <snip>
>
> Heiko has explained in another response how to fix the problem.
>
> As I understand it, it is because a recent release of pdftex is not
> backwards compatitable.
>
> Please would someone confirm that this is correct?

That's wrong.
The change is in the distribution of TeX, that the TeX compiler
for latex is pdfTeX now, used in DVI mode. Wrong code
that checks the existence of pdfTeX without looking at its
mode will break.

> And if so, also point to where this change is documented?

> Michael: Does this problem affect _all_ Python documentation?
> Or just the stuff you are authoring?

I assume *all* because the error is in the class files.
(And I recommend to use package ifpdf for python.sty and
the switch \ifpdf.)

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
May 30, 2005, 9:36:14 AM5/30/05
to
There is, in my opinion, a problem with pdftex.

(This is not to say that the macros used could not be improved.)

pdftex exits on \pdfinfo error. TeX does not exit on error.
==
$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
**\pdfoutput 0
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo


pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.

<*> \pdfinfo

No pages of output.
Transcript written on texput.log.
==


The present semantics of \pdfinfo are confused.
For example, I _can_ use \pdfinfo and generate dvi!

I just have to be a bit sneaky.
==
$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
**\pdfoutput 1
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo {}

*\pdfoutput 0

*\shipout\hbox{}
[1]
*\end
Output written on texput.dvi (1 page, 128 bytes).
==

Here, if pdf is not being generated, pdfinfo is ignored.

Suppose the semantics of \pdfinfo were something like:
\pdfinfo{ ... }
Stores information that is written to the PDF file,
if pdftex generates a PDF file. Otherwise ignored.

Then the error that prompted this thread would not have occurred.

--
Jonathan

Jonathan Fine

unread,
May 30, 2005, 10:33:36 AM5/30/05
to
Jonathan Fine wrote:
> There is, in my opinion, a problem with pdftex.

Here's another one. Again, in my opinion.

Data is written to the console, but not to the log file.
==
$ pdftex \\end


This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

{/usr/share/texmf/pdftex/config/pdftex.cfg}


No pages of output.
Transcript written on texput.log.

$ cat texput.log
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5) (format=pdftex
2005.5.25) 30 MAY 2005 15:27
**\end

No pages of output.
==

And if run with the --recorder option, pdftex.cfg is not recorded.
==
$ pdftex --recorder \\end


This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

{/usr/share/texmf/pdftex/config/pdftex.cfg}


No pages of output.
Transcript written on texput.log.

jfine@apricot:~/sourceforge/texd/texd/testdata$ cat texput.fls
PWD /home/jfine/sourceforge/texd/texd/testdata
INPUT /var/lib/texmf/web2c/pdftex.fmt
INPUT /usr/share/texmf/pdftex/config/pdftex.cfg
OUTPUT texput.log
==

--
Jonathan

Jonathan Fine

unread,
May 30, 2005, 10:44:55 AM5/30/05
to
Jonathan Fine wrote:
> And if run with the --recorder option, pdftex.cfg is not recorded.
> ==
> $ pdftex --recorder \\end
> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> {/usr/share/texmf/pdftex/config/pdftex.cfg}
> No pages of output.
> Transcript written on texput.log.
> jfine@apricot:~/sourceforge/texd/texd/testdata$ cat texput.fls
> PWD /home/jfine/sourceforge/texd/texd/testdata
> INPUT /var/lib/texmf/web2c/pdftex.fmt
> INPUT /usr/share/texmf/pdftex/config/pdftex.cfg
> OUTPUT texput.log
> ==

Oops. I withdraw this remark.

It's there, listed as an INPUT file. Apologies.

--
Jonathan

Taco Hoekwater

unread,
May 30, 2005, 11:26:51 AM5/30/05
to jf...@pytex.org
Jonathan Fine wrote:
> Jonathan Fine wrote:
>
>> There is, in my opinion, a problem with pdftex.

Perhaps you should submit a bug report. I agree with you that
there is no need for the error message seeing that you can
use trickery to avoid it anyway.

> Here's another one. Again, in my opinion.
>
> Data is written to the console, but not to the log file.

Just update your pdftex, and this problem will go away:

[taco@glenlivet tmp]$ pdftex \\end
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.3)
%&-line parsing enabled.


No pages of output.
Transcript written on texput.log.

[taco@glenlivet tmp]$ cat texput.log
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.3) (format=plain
2005.5.30) 30 MAY 2005 17:22
%&-line parsing enabled.


**\end
No pages of output.


FYI: pdftex.cfg actually *was* listed in the .fls file, but you
overlooked it. Line three was:

INPUT /usr/share/texmf/pdftex/config/pdftex.cfg

Greetings, Taco

Jonathan Fine

unread,
May 30, 2005, 1:13:12 PM5/30/05
to
Taco Hoekwater wrote:
>> Jonathan Fine wrote:
>>
>>> There is, in my opinion, a problem with pdftex.
>>
>
> Perhaps you should submit a bug report. I agree with you that
> there is no need for the error message seeing that you can
> use trickery to avoid it anyway.


Well, I've tried ... and failed!

Taco, please would you help me out on this.


I visit the pdftex home page.
http://www.tug.org/applications/pdftex/

It wrote:
Please report bugs etc. at our sarovar site.
http://sarovar.org/projects/pdftex/

So I follow the link, to get to the bug tracking system
http://sarovar.org/tracker/?atid=493&group_id=106&func=browse

And I submit a new bug:
http://sarovar.org/tracker/?func=add&group_id=106&atid=493

And I fill in the form (see below).

And I click submit.

And I get
Artifact: This ArtifactType Does Not Allow Anonymous Submissions.
Please Login.

Well, I can't login because I don't have an account.

And I don't want to sign up just so I can submit a bug report.


Taco - you're listed as a pdftex developer.

Please will you submit this bug report on my behalf

Thanks - Jonathan

========================
Subject: pdftex generates errors when it does not have to - eg \pdfinfo


pdftex generates errors when it does not have to.

This fault prevents the build of Python docs on some
platforms.

The fix may be to remove the error-generating code·

For more details, see my posting to comp.text.tex.

Google link:
<http://groups-beta.google.com/group/comp.text.tex/msg/4b4842202ce88cda?hl=en>


Copy and paste
==============


There is, in my opinion, a problem with pdftex.

(This is not to say that the macros used could not be improved.)

pdftex exits on \pdfinfo error. TeX does not exit on error.
==
$ pdftex

This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

**\pdfoutput 0
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
<*> \pdfinfo

No pages of output.
Transcript written on texput.log.
==


The present semantics of \pdfinfo are confused.
For example, I _can_ use \pdfinfo and generate dvi!

I just have to be a bit sneaky.
==
$ pdftex

This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

**\pdfoutput 1
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo {}

*\pdfoutput 0

*\shipout\hbox{}
[1]
*\end
Output written on texput.dvi (1 page, 128 bytes).
==

Here, if pdf is not being generated, pdfinfo is ignored.

Suppose the semantics of \pdfinfo were something like:
\pdfinfo{ ... }
Stores information that is written to the PDF file,
if pdftex generates a PDF file. Otherwise ignored.

Then the error that prompted this thread would not have occurred.

--
Jonathan

========================

Michael Ströder

unread,
May 30, 2005, 1:26:19 PM5/30/05
to
Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:
>
>>Michael: Does this problem affect _all_ Python documentation?
>>Or just the stuff you are authoring?
>
> I assume *all* because the error is in the class files.

I agree.

> (And I recommend to use package ifpdf for python.sty and
> the switch \ifpdf.)

Already added your patch suggestion to the bug already filed in the SF
tracker:

http://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071094&group_id=5470

Ciao, Michael.

luec...@uark.edu

unread,
May 31, 2005, 4:14:25 PM5/31/05
to

Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:
>
> > Michael Ströder wrote:
> > > HI!
> > >
> > > I'm documenting a Python module using some latex(?) templates/modules
> > > shipped with the Python 2.4.1 source distribution. This used to work for
> > > quite some while until last update of my SuSE Linux.
> >
> > <snip>
> >
> > Heiko has explained in another response how to fix the problem.
> >
> > As I understand it, it is because a recent release of pdftex is not
> > backwards compatitable.
> >
> > Please would someone confirm that this is correct?
>
> That's wrong.
> The change is in the distribution of TeX, that the TeX compiler
> for latex is pdfTeX now, used in DVI mode. Wrong code
> that checks the existence of pdfTeX without looking at its
> mode will break.

I recently checked all the styles and classes in my latex subdirectory
for this type of code (checking that \pdfoutput is defined, but not
checking its value). These may not all be errors (I didn't check in
every case how the information was used), but here they are:

changebar.sty
hcart.cls, hcreport.cls, hcslides.cls % in the hc bundle
isov2.cls
mla.sty
pbsheet.cls
science.sty
tbook.sty
ucshyper.sty


Dan

Jonathan Fine

unread,
May 31, 2005, 4:19:57 PM5/31/05
to luec...@uark.edu
luec...@uark.edu wrote:

> I recently checked all the styles and classes in my latex subdirectory
> for this type of code (checking that \pdfoutput is defined, but not
> checking its value). These may not all be errors (I didn't check in
> every case how the information was used), but here they are:
>
> changebar.sty
> hcart.cls, hcreport.cls, hcslides.cls % in the hc bundle
> isov2.cls
> mla.sty
> pbsheet.cls
> science.sty
> tbook.sty
> ucshyper.sty

It can be argued that
===


$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

**\pdfoutput = 0
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo


pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.

<*> \pdfinfo

No pages of output.
Transcript written on texput.log.
===
is a bug in pdftex. (I mean, does it have to die?)


Please let us know now many styles and classes altogether in that folder.

Just so we can get a better sense of the problem.


--
Jonathan

luec...@uark.edu

unread,
May 31, 2005, 5:06:24 PM5/31/05
to

Jonathan Fine wrote:
> luec...@uark.edu wrote:
>
> > I recently checked all the styles and classes in my latex subdirectory
> > for this type of code (checking that \pdfoutput is defined, but not
> > checking its value). These may not all be errors (I didn't check in
> > every case how the information was used), but here they are:
> >
> > changebar.sty
> > hcart.cls, hcreport.cls, hcslides.cls % in the hc bundle
> > isov2.cls
> > mla.sty
> > pbsheet.cls
> > science.sty
> > tbook.sty
> > ucshyper.sty
>

[snip]


>
> Please let us know now many styles and classes altogether in that folder.

1734 .sty files, 181 .cls files

>
> Just so we can get a better sense of the problem.

My latex directory is that provided by the TeXLive 2004 distribution,
with some local additions (about 10%), so the extent of the problem is
that (up to) 10 files should be patched, preferably by their authors.


Dan

Heiko Oberdiek

unread,
Jun 1, 2005, 5:13:04 AM6/1/05
to
Jonathan Fine <jf...@pytex.org> wrote:

It is an error in user input. \pdfinfo is not allowed in pdf mode.
Thus an error message, even a fatal one is ok.

Otherwise you get a lot of problems:
* Ignoring:
* the syntax parsing has to be doubled in the source code
* and means the user is so stupid to use pdf specific stuff
in dvi mode.
* Switching to pdf mode. Perhaps \pdfinfo is not wrong, but
the current output mode? Thus \pdfoutput could be forced to
pdf mode.

Unhappily both alternatives are excluding each other.
But pdfTeX doesn't have a clairvoyance module and cannot
know for sure what the real cause of the error was.

> Please let us know now many styles and classes altogether in that folder.
>
> Just so we can get a better sense of the problem.

As far as i could see, all these problems are macro problems.
Asking the existence of \pdfoutput is clearly *NOT* a test for
running pdfTeX in pdf mode. Also the value of \pdfoutput has
to be respected.

Thus the bugs in macro code should be fixed.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Sine Nomine

unread,
Jun 1, 2005, 11:18:15 AM6/1/05
to
On 31/05/05 21:19, Jonathan Fine wrote:
> It can be argued that
> ===
> $ pdftex
> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> **\pdfoutput = 0
> {/usr/share/texmf/pdftex/config/pdftex.cfg}
> *\pdfinfo
> pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> <*> \pdfinfo
>
> No pages of output.
> Transcript written on texput.log.
> ===
> is a bug in pdftex.

You have a strange definition of bug.

Jonathan Fine

unread,
Jun 1, 2005, 4:17:23 PM6/1/05
to


In fact what I wrote was:


> is a bug in pdftex. (I mean, does it have to die?)


In TeX a misplaced primitive never causes an exit.
(Except for \end and \dump of course.)

Don Knuth took the trouble of keeping TeX going. For example,
change #864 helps TeX run longer when it's running out of memory.

He called it an error rather than a bug.


pdftex is an extension of TeX.

In my opinion, and by the standards of TeX, the above
response to an error _is_ an error. (Even if it is not
a bug.)


And there is also the following to consider:


===
$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)

**\pdfoutput = 1
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo {whatever}

*\pdfoutput = 0

*
===

Now we have \pdfinfo = 0 and we \pdfoutput is 'unset'.

So what is the point of the forced exit above?

--
Jonathan

Jonathan Fine

unread,
Jun 1, 2005, 4:23:26 PM6/1/05
to
Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:

<snip>

>>It can be argued that
>>===
>>$ pdftex
>>This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
>>**\pdfoutput = 0
>>{/usr/share/texmf/pdftex/config/pdftex.cfg}
>>*\pdfinfo
>>pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
>><*> \pdfinfo
>>
>>No pages of output.
>>Transcript written on texput.log.
>>===
>>is a bug in pdftex. (I mean, does it have to die?)
>
>
> It is an error in user input. \pdfinfo is not allowed in pdf mode.
> Thus an error message, even a fatal one is ok.

<snip>

TeX does not die, when there are errors in the input.

pdftex, as we can see above, does.
I regard this as a bug (or more objectively, an error).

Heiko, can we agree on that?

--
Jonathan


Heiko Oberdiek

unread,
Jun 1, 2005, 4:40:40 PM6/1/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Heiko Oberdiek wrote:
> > Jonathan Fine <jf...@pytex.org> wrote:
>
> <snip>
>
> >>It can be argued that
> >>===
> >>$ pdftex
> >>This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> >>**\pdfoutput = 0
> >>{/usr/share/texmf/pdftex/config/pdftex.cfg}
> >>*\pdfinfo
> >>pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> >><*> \pdfinfo
> >>
> >>No pages of output.
> >>Transcript written on texput.log.
> >>===
> >>is a bug in pdftex. (I mean, does it have to die?)
> >
> >
> > It is an error in user input. \pdfinfo is not allowed in pdf mode.
> > Thus an error message, even a fatal one is ok.
>
> <snip>
>
> TeX does not die, when there are errors in the input.

pdfTeX only uses "succumb" here, it is a web macro of the
original tex.web source. It is called here by
* procedure overflow
* procedure confusion
* Errors by \dump, e.g.
call iniTeX on "\begingroup\dump\endgroup"

> pdftex, as we can see above, does.
> I regard this as a bug (or more objectively, an error).
>
> Heiko, can we agree on that?

Also TeX dies, so we can agree, that this is not a bug. :-)

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Heiko Oberdiek

unread,
Jun 1, 2005, 4:55:08 PM6/1/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Sine Nomine wrote:
> > On 31/05/05 21:19, Jonathan Fine wrote:
> >
> >> It can be argued that
> >> ===
> >> $ pdftex
> >> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> >> **\pdfoutput = 0
> >> {/usr/share/texmf/pdftex/config/pdftex.cfg}
> >> *\pdfinfo
> >> pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> >> <*> \pdfinfo
> >>
> >> No pages of output.
> >> Transcript written on texput.log.
> >> ===
> >> is a bug in pdftex.
> >
> >
> > You have a strange definition of bug.
>
>
> In fact what I wrote was:
> > is a bug in pdftex. (I mean, does it have to die?)
>
>
> In TeX a misplaced primitive never causes an exit.
> (Except for \end and \dump of course.)

Thus you have found yourself primitives that causes exits (succumb).
\pdfinfo and some others are just another ones.

> Don Knuth took the trouble of keeping TeX going. For example,
> change #864 helps TeX run longer when it's running out of memory.
>
> He called it an error rather than a bug.
>
>
> pdftex is an extension of TeX.
>
> In my opinion, and by the standards of TeX, the above
> response to an error _is_ an error. (Even if it is not
> a bug.)

Where is your problem. You have written, pdfTeX is an extension.
Thus primitives that cause error exits are extended. And calling
the behaviour as an error or bug, if pdfTeX generates an error
because of an error in the input, is quite rediculous.

> And there is also the following to consider:
> ===
> $ pdftex
> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> **\pdfoutput = 1
> {/usr/share/texmf/pdftex/config/pdftex.cfg}
> *\pdfinfo {whatever}
>
> *\pdfoutput = 0
>
> *
> ===
>
> Now we have \pdfinfo = 0 and we \pdfoutput is 'unset'.
>
> So what is the point of the forced exit above?

What's you problem, here the mode is correct during
executing \pdfinfo. In the above example the mode
was not correct. \pdfinfo does not make sense in
DVI mode, thus its use is allowed in PDF mode only,
otherwise an error occurs. I think this is easy to understand
and the error helps in correcting user input.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
Jun 1, 2005, 4:55:50 PM6/1/05
to
Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:

<snip>

>>TeX does not die, when there are errors in the input.


>
>
> pdfTeX only uses "succumb" here, it is a web macro of the
> original tex.web source. It is called here by
> * procedure overflow
> * procedure confusion
> * Errors by \dump, e.g.
> call iniTeX on "\begingroup\dump\endgroup"


In this posting I forgot, and in another remembered, to say


> (Except for \end and \dump of course.)


Here is the definition of succumb.
===
@d succumb==begin if interaction=error_stop_mode then
interaction:=scroll_mode; {no more interaction}
if log_opened then error;
@!debug if interaction>batch_mode then debug_help;@+gubed@;@/
history:=fatal_error_stop; jump_out; {irrecoverable error}
end
===

To be used for 'irrecoverable error'.

Strictly speaking, a misplaced \dump is not an irrecoverable
error. One could instead treat it as a null-op.

However, that means that a misplaced \dump does not \end
the run of TeX.


The other useages of succumb, as you list above, are
irrecoverable errors.

For example
====
@<Error hand...@>=
procedure overflow(@!s:str_number;@!n:integer); {stop due to finiteness}
begin normalize_selector;
print_err("TeX capacity exceeded, sorry [");
@.TeX capacity exceeded ...@>
print(s); print_char("="); print_int(n); print_char("]");
help2("If you really absolutely need more capacity,")@/
("you can ask a wizard to enlarge me.");
succumb;
end;

====

Now, it seems to me that
\pdfoutput = 0
\pdfinfo {whatever}
is a recoverable error.

In fact, its semantics are pretty much the same as
\pdfoutput = 0
\begingroup
\pdfoutput = 1
\pdfinfo {whatever}
\endgroup

And this _is_ allowed by pdftex.

--
Jonathan

David Kastrup

unread,
Jun 1, 2005, 5:17:01 PM6/1/05
to
Jonathan Fine <jf...@pytex.org> writes:

> Sine Nomine wrote:
>> On 31/05/05 21:19, Jonathan Fine wrote:
>>
>>> It can be argued that
>>> ===
>>> $ pdftex
>>> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
>>> **\pdfoutput = 0
>>> {/usr/share/texmf/pdftex/config/pdftex.cfg}
>>> *\pdfinfo
>>> pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
>>> <*> \pdfinfo
>>>
>>> No pages of output.
>>> Transcript written on texput.log.
>>> ===
>>> is a bug in pdftex.
>> You have a strange definition of bug.
>
>
> In fact what I wrote was:
> > is a bug in pdftex. (I mean, does it have to die?)
>
>
> In TeX a misplaced primitive never causes an exit.
> (Except for \end and \dump of course.)

dak@lola:~$ tex '\nonstopmode \input panic!'
This is TeX, Version 3.14159 (Web2C 7.4.5)

! I can't find file `panic!'.
<*> \nonstopmode \input panic!

Please type another input file name
! Emergency stop.
<*> \nonstopmode \input panic!



No pages of output.
Transcript written on texput.log.

dak@lola:~$ tex '\halign{&#\cr\multispan{260}{x}\cr}'
This is TeX, Version 3.14159 (Web2C 7.4.5)
! This can't happen (256 spans).
<template> \endtemplate

<*> \halign{&#\cr\multispan{260}{x}\cr


}
No pages of output.
Transcript written on texput.log.

dak@lola:~$ tex '\def~{\if~}~'
This is TeX, Version 3.14159 (Web2C 7.4.5)
Segmentation fault

dak@lola:~$ tex '\def~{~~}~'
This is TeX, Version 3.14159 (Web2C 7.4.5)
! TeX capacity exceeded, sorry [input stack size=1500].
~->~
~
~->~
~
~->~
~
~->~
~
~->~
~
~->~
~
...
<*> \def~{~~}~



No pages of output.
Transcript written on texput.log.

dak@lola:~$ tex '&pdftex'
This is TeX, Version 3.14159 (Web2C 7.4.5)
(Fatal format file error; I'm stymied)
dak@lola:~$

> In my opinion, and by the standards of TeX, the above
> response to an error _is_ an error. (Even if it is not
> a bug.)

Could you explain what makes the behavior different in quality from
_all_ of the above examples?

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>

Jonathan Fine

unread,
Jun 1, 2005, 5:37:53 PM6/1/05
to
David Kastrup wrote:

<snip>

> dak@lola:~$ tex '\nonstopmode \input panic!'
> This is TeX, Version 3.14159 (Web2C 7.4.5)
>
> ! I can't find file `panic!'.
> <*> \nonstopmode \input panic!
>
> Please type another input file name
> ! Emergency stop.
> <*> \nonstopmode \input panic!
>
> No pages of output.
> Transcript written on texput.log.


The above is not a minimal example. The \input is a distraction.
==
$ tex '\nonstopmode'


This is TeX, Version 3.14159 (Web2C 7.4.5)

! Emergency stop.
<*> \nonstopmode

No pages of output.
Transcript written on texput.log.
==

<other error conditions snipped>


> Could you explain what makes the behavior different in quality from
> _all_ of the above examples?


Pleased to oblige.

As far as I can tell, _all_ the errors you supplied are irrecoverable.

If you disagree, please tell me what the recovery should be.


Whereas "\pdfinfo used while \pdfoutput is not set" is recoverable.

(If indeed it is an error.)

And elsewhere in this thread I indicate what the recovery should be.

--
Jonathan

Heiko Oberdiek

unread,
Jun 1, 2005, 6:12:16 PM6/1/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Now, it seems to me that
> \pdfoutput = 0
> \pdfinfo {whatever}
> is a recoverable error.

No, only by accident. I have already explained there are
several reasons for the error:
* wrong output mode
* wrong \pdfinfo token

It is not possible to fix both reasons at the same time:
* setting output mode to PDF and processing \pdfinfo
* output mode is unchanged (DVI) and ignoring \pdfinfo

Either way pdfTeX chooses, it does not have a chance
to avoid a following bug report that it has choosen the wrong
way. Thus the currrent fatal error message is a good choice,
because it is
* easy to understand,
* easy to document,
* easy to maintain.

> In fact, its semantics are pretty much the same as
> \pdfoutput = 0
> \begingroup
> \pdfoutput = 1
> \pdfinfo {whatever}
> \endgroup

Now you have a special semantics for \pdfinfo.
It is meaningful for PDF mode only, but it is allowed
in other modes also and its value is remembered,
if the mode changes.
Perhaps this semantics could be easily implemented,
this will not be the case for many of the other primitives
of pdf mode. Thus you have then a solution:
* more difficult to understand, because of
different semantics of pdf mode's primitives
* more difficult to document, because of
different semantics of pdf mode's primitives
* more difficult to maintain

I think better than this, would be a semantics of
a error message that recovers by ignoring.
Because this will work for all primitives of pdf output mode:
* easy to understand
* easy to document
* maintanance penalty by adding syntax
parsing twice (one for real action, one
for ignoring).

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Donald Arseneau

unread,
Jun 1, 2005, 6:22:56 PM6/1/05
to
Heiko Oberdiek <ober...@uni-freiburg.de> writes:

> Jonathan Fine <jf...@pytex.org> wrote:
>
> > Heiko Oberdiek wrote:
> > > It is an error in user input. \pdfinfo is not allowed in pdf mode.
> > > Thus an error message, even a fatal one is ok.

I don't see why you are so quick to jump from a standard error message
to a fatal stoppage.

> pdfTeX only uses "succumb" here, it is a web macro of the
> original tex.web source. It is called here by
> * procedure overflow
> * procedure confusion
> * Errors by \dump, e.g.
> call iniTeX on "\begingroup\dump\endgroup"

Things that are intrinsically fatal, not just erroneous. I don't see
any reason why \pdfinfo must succumb. If there were something that prevents
it from checking the \pdfoutput state, then it should succumb when it
actually attempted to write the pdf-info, but sensible programming
would have it check \pdfoutput first, and issue a normal error in
dvi mode.

> Also TeX dies, so we can agree, that this is not a bug. :-)

The things DK listed are mostly bugs in TeX that the other DK
will not fix. There is no reason to emulate that.

(Strange as it is to be agreeing with JF, it is stranger yet to
have others wanting to emulate Knuth's mistakes.)


--
Donald Arseneau as...@triumf.ca

luec...@uark.edu

unread,
Jun 1, 2005, 7:02:29 PM6/1/05
to

Jonathan Fine wrote:

> > Could you explain what makes the behavior different in quality from
> > _all_ of the above examples?
>
>
> Pleased to oblige.
>
> As far as I can tell, _all_ the errors you supplied are irrecoverable.
>
> If you disagree, please tell me what the recovery should be.
>
>
> Whereas "\pdfinfo used while \pdfoutput is not set" is recoverable.

I have to agree. In my opinion the most logical handling of any of the
\pdf... commands that make no sense in dvi mode is to consider them
undefined.

I seem to remember that etex does something like that with regard to
its extensions when not in extended mode.

Moreover, the current latex.ini file calls pdftex-dvi.tex, which
explicitly undefines those commands, forcing this behavior. It seems
that the writer of that file agrees that use of \pdfinfo in dvi mode
should not cause TeX to die (or succomb).


Dan

Donald Arseneau

unread,
Jun 2, 2005, 2:04:25 AM6/2/05
to
Heiko Oberdiek <ober...@uni-freiburg.de> writes:

> Jonathan Fine <jf...@pytex.org> wrote:
>
> > Now, it seems to me that
> > \pdfoutput = 0
> > \pdfinfo {whatever}
> > is a recoverable error.
>
> No, only by accident. I have already explained there are
> several reasons for the error:
> * wrong output mode
> * wrong \pdfinfo token
>
> It is not possible to fix both reasons at the same time:
> * setting output mode to PDF and processing \pdfinfo
> * output mode is unchanged (DVI) and ignoring \pdfinfo


It doesn't have to know what action to take! It should just throw an error
like other TeX errors, and maybe the user can clean up, or maybe not.

If it is the wrong output mode, then the user can type "x" or
i
\pdfoutput=1

If \pdfinfo was there accidentally, the user can type "e" or
1
i
\mbox

I like the solution of having \pdfinfo undefined in dvi output mode.

--
Donald Arseneau as...@triumf.ca

David Kastrup

unread,
Jun 2, 2005, 4:59:26 AM6/2/05
to
Donald Arseneau <as...@triumf.ca> writes:

> If it is the wrong output mode, then the user can type "x" or
> i
> \pdfoutput=1
>
> If \pdfinfo was there accidentally, the user can type "e" or
> 1
> i
> \mbox
>
> I like the solution of having \pdfinfo undefined in dvi output mode.

That's absolute lunacy since \pdfoutput is only fixed after the first
\shipout. You don't want a macro that magically defines and undefines
itself depending on the setting of a different variable. The
interactions with the save stack and table of equivalence are in a
completely new class of potential errors you don't want to think
about.

David Kastrup

unread,
Jun 2, 2005, 5:06:02 AM6/2/05
to
Donald Arseneau <as...@triumf.ca> writes:

> If it is the wrong output mode, then the user can type "x" or
> i
> \pdfoutput=1
>
> If \pdfinfo was there accidentally, the user can type "e" or
> 1
> i
> \mbox
>
> I like the solution of having \pdfinfo undefined in dvi output mode.

That's absolute lunacy since \pdfoutput is only fixed after the first


\shipout. You don't want a macro that magically defines and undefines
itself depending on the setting of a different variable. The
interactions with the save stack and table of equivalence are in a
completely new class of potential errors you don't want to think
about.

Two observations:

a) it would appear that the variable is a candidate for a global
variable which would get rid of the save stack dependencies.

b) it might be reasonable to just let any assignments to it happen.
Then at \shipout time, it gets consulted. If it has been set even
though \pdfoutput is 0, the pdfinfo is flushed and an error message
given.

Heiko Oberdiek

unread,
Jun 2, 2005, 5:13:13 AM6/2/05
to
luec...@uark.edu wrote:

> Jonathan Fine wrote:
>
> > > Could you explain what makes the behavior different in quality from
> > > _all_ of the above examples?
> >
> >
> > Pleased to oblige.
> >
> > As far as I can tell, _all_ the errors you supplied are irrecoverable.
> >
> > If you disagree, please tell me what the recovery should be.
> >
> >
> > Whereas "\pdfinfo used while \pdfoutput is not set" is recoverable.
>
> I have to agree. In my opinion the most logical handling of any of the
> \pdf... commands that make no sense in dvi mode is to consider them
> undefined.

Then the users don't know what went wrong. Are they using a not
uptodate version. Are there typos in the manual about spelling
command names, ...
Therefore I would prefer a descriptive error message.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Heiko Oberdiek

unread,
Jun 2, 2005, 5:13:13 AM6/2/05
to
Donald Arseneau <as...@triumf.ca> wrote:

> Heiko Oberdiek <ober...@uni-freiburg.de> writes:
>
> > Jonathan Fine <jf...@pytex.org> wrote:
> >
> > > Heiko Oberdiek wrote:
> > > > It is an error in user input. \pdfinfo is not allowed in pdf mode.
> > > > Thus an error message, even a fatal one is ok.
>
> I don't see why you are so quick to jump from a standard error message
> to a fatal stoppage.

I think, a non fatal error message with ignoring the arguments
is also ok, but someone has to implement and maintain this
behaviour. Who?

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
Jun 2, 2005, 4:14:27 PM6/2/05
to
David Kastrup wrote:

<snip>

> b) it might be reasonable to just let any assignments to it happen.
> Then at \shipout time, it gets consulted. If it has been set even
> though \pdfoutput is 0, the pdfinfo is flushed and an error message
> given.

Here 'it' is \pdfinfo.

I'm glad that you now recognise that there is some sort of error
in the way pdftex handles \pdfinfo when \pdfoutput is zero.


Your suggestion is similar to one I made earlier in thread:


> Now, it seems to me that
> \pdfoutput = 0
> \pdfinfo {whatever}
> is a recoverable error.
>

> In fact, its semantics are pretty much the same as
> \pdfoutput = 0
> \begingroup
> \pdfoutput = 1
> \pdfinfo {whatever}
> \endgroup
>

> And this _is_ allowed by pdftex.

Here 'its' means the recovery from error.


You suggest that \pdfinfo is flushed. In the situation you
describe, I don't see how the user can know that \pdfinfo
has been flushed. Do you see any way?


--
Jonathan

David Kastrup

unread,
Jun 2, 2005, 4:43:54 PM6/2/05
to
Jonathan Fine <jf...@pytex.org> writes:

> David Kastrup wrote:
>
> <snip>
>
>> b) it might be reasonable to just let any assignments to it happen.
>> Then at \shipout time, it gets consulted. If it has been set even
>> though \pdfoutput is 0, the pdfinfo is flushed and an error message
>> given.
>
> Here 'it' is \pdfinfo.
>
> I'm glad that you now recognise that there is some sort of error
> in the way pdftex handles \pdfinfo when \pdfoutput is zero.

Don't put words into my mouths. Not everything for which there might
be a possibly more desirable alternative is an error.

If it were, Knuth were broke by now.

David Kastrup

unread,
Jun 2, 2005, 4:44:03 PM6/2/05
to
Jonathan Fine <jf...@pytex.org> writes:

> David Kastrup wrote:
>
> <snip>
>
>> b) it might be reasonable to just let any assignments to it happen.
>> Then at \shipout time, it gets consulted. If it has been set even
>> though \pdfoutput is 0, the pdfinfo is flushed and an error message
>> given.
>
> Here 'it' is \pdfinfo.
>
> I'm glad that you now recognise that there is some sort of error
> in the way pdftex handles \pdfinfo when \pdfoutput is zero.

Don't put words into my mouth. Not everything for which there might


be a possibly more desirable alternative is an error.

If it were, Knuth were broke by now.

--

Jonathan Fine

unread,
Jun 3, 2005, 3:12:41 AM6/3/05
to
David Kastrup wrote:
> Jonathan Fine <jf...@pytex.org> writes:

<snip>

>>I'm glad that you now recognise that there is some sort of error
>>in the way pdftex handles \pdfinfo when \pdfoutput is zero.
>
>
> Don't put words into my mouths. Not everything for which there might
> be a possibly more desirable alternative is an error.


I withdraw my remark. As you put it, there might possibly be a
more desirable alternative.


Recall that this is the behaviour at issue.


==
$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
**\pdfoutput = 0
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
<*> \pdfinfo

No pages of output.
Transcript written on texput.log.
==

Here, pdftex does not have to die. But it does.

I regard this as an error, or bug, in pdftex.

How would you describe it?

--
Jonathan

Heiko Oberdiek

unread,
Jun 3, 2005, 4:57:15 AM6/3/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Recall that this is the behaviour at issue.
> ==
> $ pdftex
> This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
> **\pdfoutput = 0
> {/usr/share/texmf/pdftex/config/pdftex.cfg}
> *\pdfinfo
> pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
> <*> \pdfinfo
>
> No pages of output.
> Transcript written on texput.log.
> ==
>
> Here, pdftex does not have to die. But it does.
>
> I regard this as an error, or bug, in pdftex.

An error as reaction to invalid input is never a bug.
It is a feature that the invalid input is recognized.

> How would you describe it?

If you want to have another behaviour, then this
is a feature request.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
Jun 6, 2005, 3:11:32 PM6/6/05
to
David Kastrup wrote:
> Donald Arseneau <as...@triumf.ca> writes:

<snip>

>>I like the solution of having \pdfinfo undefined in dvi output mode.
>
>
> That's absolute lunacy

<snip>

> it might be reasonable to just let any assignments to it happen.
> Then at \shipout time, it gets consulted. If it has been set even
> though \pdfoutput is 0, the pdfinfo is flushed and an error message
> given.


That's not a good idea, in my opinion.

Suppose that it is pdfinitex that is shipping out a page.

pdfinitex can the \dump the state.

Including the value of \pdfinfo.

So why flush it?


I find Donald's suggestion as sensible as yours.

--
Jonathan

Jonathan Fine

unread,
Jun 6, 2005, 3:31:23 PM6/6/05
to

pdftex is an extension of TeX.

I apply to it the same standards as Don Knuth applied to TeX.

It is treated by many as a successor to TeX, so I think
that doing so is reasonable.


In 'The Errors of TeX' he wrote defined a class of errors:
==
{\bf R}, are reinforcement of robustness. Whenever I
realized that TeX could loop or crash in the presence
of certain erroneous input, I tired to make the code
bulletproof.
==

There are many 'R' errors in the error log of TeX.

The last entry (Digital Typography, p656) is:
{\bf 933} Avoid spurious reference count in format files (PB)

Of this error, Don wrote (loc cit, p658):
> This error, discovered in 1995 by Peter Breitenlohner, is
> rather esoteric and it has not effect on normal use; yet
> I believe he amply deserved the reward of $327.68 that I
> paid him on 20 March 1995.


Therefore, I describe the \pdfinfo 'feature' as an error.

By describing it as just a feature, you do not make pdftex
any better as a program. Just as my describing it as an
error does not make it any worse.

You and I are applying different standards, hence my
describing this 'feature' as an 'error'.


--
Jonathan

David Kastrup

unread,
Jun 6, 2005, 3:35:37 PM6/6/05
to
Jonathan Fine <jf...@pytex.org> writes:

Actually, I consider the idea of actually shipping pages in PDF or DVI
mode, then using \dump, and then trying to switch to a different
output mode, disturbing at best.

I am not sure that the code is designed to cater for that.

Jonathan Fine

unread,
Jun 6, 2005, 3:43:49 PM6/6/05
to
David Kastrup wrote:

> Actually, I consider the idea of actually shipping pages in PDF or DVI
> mode, then using \dump, and then trying to switch to a different
> output mode, disturbing at best.
>
> I am not sure that the code is designed to cater for that.

It's fairly easy to test if this works ... sometimes.

But testing will show only the presence of bugs.

Not their absence.


Don Knuth belongs to the old school - those who at least
aspired to prove that their program was correct.


Whichever way you look at it, I think there's an error in pdftex.

Either:
A. Switching between PDF and dvi with a \dump between does NOT
work properly

or:
B. The code


\pdfoutput = 1
\pdfinfo{whatever}

causes pdftex to needlessly exit.


My inclination is that (A) works fine, and that (B) is the
error.

--
Jonathan

David Kastrup

unread,
Jun 6, 2005, 3:51:29 PM6/6/05
to
Jonathan Fine <jf...@pytex.org> writes:

> pdftex is an extension of TeX.
>
> I apply to it the same standards as Don Knuth applied to TeX.

You happen not to be in the same position regarding PDFTeX as Knuth is
with regard to TeX.

> You and I are applying different standards, hence my
> describing this 'feature' as an 'error'.

Knuth once said that he desired TeX to be used as a foundation for
further work to be based on it. Since you have been quoting this
sentiment of his generously, you should be somewhat aware of it.

Now while your contributions suggest that you prefer your windows to
be made of the same quality concrete as your quarter's foundation,
other people might prefer the less durable variant of glass for that
purpose, of course with the disadvantage that it is more likely to be
smashed by hooligans.

Jonathan Fine

unread,
Jun 6, 2005, 4:53:03 PM6/6/05
to
David Kastrup wrote:
> Jonathan Fine <jf...@pytex.org> writes:
>
>
>>pdftex is an extension of TeX.
>>
>>I apply to it the same standards as Don Knuth applied to TeX.
>
>
> You happen not to be in the same position regarding PDFTeX as Knuth is
> with regard to TeX.
>
>
>>You and I are applying different standards, hence my
>>describing this 'feature' as an 'error'.
>
>
> Knuth once said that he desired TeX to be used as a foundation for
> further work to be based on it. Since you have been quoting this
> sentiment of his generously, you should be somewhat aware of it.


Indeed. I quoted this passage from "The Future of TeX and METAFONT"
in my EuroTeX 2005 paper:
==
Of course I do not claim to have found the best solution to every
problem. I simply claim that it is a great advantage to have a
fixed point as a building block. Improved macro packages can be
added on the input side; improved device drivers can be added on the
output~side.
==

Both you and I were present at EuroTeX, so you've had a chance to
read my paper.

For the past ten years or so I have advocated improved macro
packages and improved device drivers, and spent much time
pursuing such goals.

Generating pdf from dvi is, of course, an example of an improved
device driver.


Knuth then went on to say:
==
I welcome continued research that will lead to alternative systems
that will typeset documents better than TeX is able to do. But the
authors of such systems must think of another name.
==

It is true that I quote this passage less often. Because I think the
creation of such alternative systems is not a pressing matter.


TeX is a fixed point. pdftex is not.

pdftex does not typeset the documents I deal with better than TeX
does. In fact, it typesets them identically.


> Now while your contributions suggest that you prefer your windows to
> be made of the same quality concrete as your quarter's foundation,
> other people might prefer the less durable variant of glass for that
> purpose, of course with the disadvantage that it is more likely to be
> smashed by hooligans.

You are 'suggesting' words into my mouth.

Just so there be no doubt, I prefer glass to concrete in windows.

And I prefer TeX to pdftex. But that is a side issue.

For me, the key issue, TeX or pdftex, is improved macro packages
and improved device drivers.

--
Jonathan

Heiko Oberdiek

unread,
Jun 7, 2005, 8:07:19 AM6/7/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> B. The code
> \pdfoutput = 1
> \pdfinfo{whatever}
> causes pdftex to needlessly exit.

Unhappily no. \pdfinfo does not check the validity of its input.
"whatever" is not valid, key value pairs are expected. Checking
the validity would require the parsing of PDF objects.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Heiko Oberdiek

unread,
Jun 7, 2005, 8:07:19 AM6/7/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> pdftex is an extension of TeX.
>
> I apply to it the same standards as Don Knuth applied to TeX.
>
> It is treated by many as a successor to TeX, so I think
> that doing so is reasonable.

Sorry, I don't understand your problem.
If your problem is the missing error recovery,
then this also applies to iniTeX:
\begingroup\dump

Eg. error recovery is possible by ignoring \dump or
by closing all open groups. Thus TeX uses fatal
error messages on errorneous input.
\pdfinfo in wrong mode behaves the same way
and is therefore in "good" tradition of TeX.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Jonathan Fine

unread,
Jun 7, 2005, 3:12:12 PM6/7/05
to
Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:
>
>
>>B. The code
>> \pdfoutput = 1
>> \pdfinfo{whatever}
>>causes pdftex to needlessly exit.
>
>
> Unhappily no. \pdfinfo does not check the validity of its input.
> "whatever" is not valid, key value pairs are expected. Checking
> the validity would require the parsing of PDF objects.


Sorry, I made a typo. It should be '0', not '1'.

Here's a correct copy.
===


$ pdftex
This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5)
**\pdfoutput = 0
{/usr/share/texmf/pdftex/config/pdftex.cfg}
*\pdfinfo
pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
<*> \pdfinfo

No pages of output.
Transcript written on texput.log.

===

--
Jonathan

Heiko Oberdiek

unread,
Jun 8, 2005, 4:16:11 AM6/8/05
to
Jonathan Fine <jf...@pytex.org> wrote:

> Heiko Oberdiek wrote:
> > Jonathan Fine <jf...@pytex.org> wrote:
> >
> >
> >>B. The code
> >> \pdfoutput = 1
> >> \pdfinfo{whatever}
> >>causes pdftex to needlessly exit.
> >
> >
> > Unhappily no. \pdfinfo does not check the validity of its input.
> > "whatever" is not valid, key value pairs are expected. Checking
> > the validity would require the parsing of PDF objects.
>
>
> Sorry, I made a typo. It should be '0', not '1'.

Yes, but the typo is much more interesting.
In both cases the user input is wrong. The
case \pdfoutput=0 is catched by pdfTeX.
But pdfTeX generates a pdf file with
\pdfinfo{whatever} in PDF mode.
The result, however, is not a valid PDF file.
Ghostscript, xpdf, acroread will not show errors,
however in acroread all information entries
are empty. pdfinfo prints an error message, but
shows the entries.

Thus I think there is a need for better output
validation of pdfTeX or a program that validates
pdf files.

Yours sincerely
Heiko <ober...@uni-freiburg.de>

Reply all
Reply to author
Forward
0 new messages