pdftex broken in tetex-3: offsets incorrect

The following trivial tex file is rendered incorrectly by pdfetex, which
is the default version of pdftex in tetex-3.
\magnification \magstep5
\parindent 0pt
\hoffset -1 truein
\voffset -1 truein
The top
\end

Clearly the offsets, and by the way the page size, is incorrectly
handled by pdfetex. This is a serious problem if pdfetex is going to
become the pdftex of choice.

Anyone know of a fix for this?

Ian Hutchinson

On Sat, 28 Jan 2006 03:08:47 +0100, Ian Hutchinson <ihutch@verizon.net>
wrote:

> The following trivial tex file is rendered incorrectly by pdfetex, which
> is the default version of pdftex in tetex-3.
> \magnification \magstep5
> \parindent 0pt
> \hoffset -1 truein
> \voffset -1 truein
> The top
> \end
>
> Clearly the offsets, and by the way the page size, is incorrectly
> handled by pdfetex. This is a serious problem if pdfetex is going to
> become the pdftex of choice.
>
> Anyone know of a fix for this?

See the messages starting at
<http://www.ntg.nl/pipermail/ntg-pdf...ary/001987.html>.
--
Morten

Morten Høgholm wrote:
> On Sat, 28 Jan 2006 03:08:47 +0100, Ian Hutchinson <ihutch@verizon.net>
> wrote:
> 
>
>
> See the messages starting at
> <http://www.ntg.nl/pipermail/ntg-pdf...ary/001987.html>.

Thanks for that reference, it is definitely on topic, but very
definitely not a fix. Just to clarify. The above trivial program works
correctly to put "The top" at the top left of the page in tex, but using
pdftex (in tetex-3.0..) puts it in an incorrect position somewhat into
the page. Only for \magstep0 does pdftex put it in the right place.
Clearly there is an error in the calculation of the position and offsets
within the new pdfetex (an error which was never there before) when
\magnification is being used. Responses in the thread miss the point and
talk about ifpdf.sty etc which is irrelevant here.

Ian

Ian Hutchinson <hutch@hutchinson.belmont.ma.us> wrote:

> Morten Høgholm wrote: 
>
> Thanks for that reference, it is definitely on topic, but very
> definitely not a fix. Just to clarify. The above trivial program works
> correctly to put "The top" at the top left of the page in tex, but using
> pdftex (in tetex-3.0..) puts it in an incorrect position somewhat into
> the page. Only for \magstep0 does pdftex put it in the right place.

pdfTeX adds a new feature, \pdfhorigin and \pdfvorigin. After changing
\magnification you have to correct these two values:
\magnification ...
\pdfhorigin 1 true in
\pdfvorigin 1 true in
This is the price for a new feature and the akward annoying behaviour
of original TeX that puts the origin at a random place on the page.

> Clearly there is an error in the calculation of the position and offsets
> within the new pdfetex (an error which was never there before) when
> \magnification is being used. Responses in the thread miss the point and
> talk about ifpdf.sty etc which is irrelevant here.

Probably your reading glasses need some corrections.

* The OP in this thread has provided an example and compares
"tex" with "pdftex". However, the example isn't running with "tex".
The use of ifpdf.sty and \ifpdf just fixes the example. If you would
have tried the example, then you would have seen that this is
relevant.
* The same mail explains the use of \pdfhorigin and \pdfvorigin,
how the example can be rewritten to get correct results for both
"tex" and "pdftex".
* And you should read the answer of Martin, perhaps it has not
yet hit the archives. He quotes the pdfTeX manual
(http://www.pdftex.org/):

| - \pdfhorigin (dimension)
| This parameter can be used to set the horizontal offset the
| output box from the top left corner of the page. A value of 1
| inch corresponds to the normal TeX offset.  This parameter is
| read when pdfTeX starts shipping out a page to the pdf output.
|
| For standard purposes, this parameter should always be kept at 1
| true inch. If you want to shift text on the page, use TeX's own
| \hoffset primitive. To avoid surprises, after global
| magnification has been changed by the \mag primitive, the
| \pdfhorigin parameter should still be 1 true inch, e. g. by
| typing \pdfhorigin=1 true in after issuing the \mag command. Or,
| you can preadjust the \pdfhorigin value before typing \mag, so
| that its value after the \mag command ends up at 1 true inch
| again.
|
| - \pdfvorigin (dimension)
| This parameter is the vertical companion of \pdfhorigin, and the
| notes above regarding \mag and true dimensions apply. Also keep
| in mind that the TeX coordinate system starts in the top left
| corner (downward), while pdf coordinates start at the bottom left
| corner (upward).

\magnification \magstep5

\input ifpdf.sty
\ifpdf
% required after global use of \magnification:
\pdfhorigin 1 true in
\pdfvorigin 1 true in
% example, setting for A4 paper:
\pdfpagewidth 210mm
\pdfpageheight 297mm
\fi

\parindent 0pt
\topskip 0pt
\hoffset -1 truein
\voffset -1 truein
The top
\end

And regarding the changes in pdfTeX, see the second answer of Martin:

| 1.20a corrected this. See the thread at
| http://www.ntg.nl/pipermail/ntg-pdf...ril/000485.html

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

Heiko Oberdiek wrote:
> Ian Hutchinson <hutch@hutchinson.belmont.ma.us> wrote: 
... 
>
>
> pdfTeX adds a new feature, \pdfhorigin and \pdfvorigin. After changing
> \magnification you have to correct these two values:
>   \magnification ...
>   \pdfhorigin 1 true in
>   \pdfvorigin 1 true in
> This is the price for a new feature and the akward annoying behaviour
> of original TeX that puts the origin at a random place on the page.

Dear Heiko: First, thanks for all the work you've done on pdftex. I, for
one truly appreciate it. But now, the "price for a new feature" is way
too high. You've broken any prior document that uses \magnification and
changes \hoffset.

It is true that TeX is somewhat annoying at choosing +1in,+1in as its
standard starting point. But we can't simply ignore that and pretend it
did not happen. And we have not been doing so for all the prior life of
pdftex.
 
>
>
> Probably your reading glasses need some corrections.
>
> * The OP in this thread has provided an example and compares
>   "tex" with "pdftex". However, the example isn't running with "tex".
>   The use of ifpdf.sty and \ifpdf just fixes the example. If you would
>   have tried the example, then you would have seen that this is
>   relevant.

If I understand you right, you are saying that if I add some code at the
top of the plain tex file I have given as an example, I can fix it.
Undoubtedly that is true, but it is irrelevant to my point, which is
that introducing new features into pdftex SHOULD NOT cause the most
basic of tex documents to be incorrectly rendered in pdf. If it is
deliberate that this happens, I can only say that I think it is a
terrible mistake. For years pdftex has done just what tex does with such
files. Suddenly now, you are going to change it?!

> * The same mail explains the use of \pdfhorigin and \pdfvorigin,
>   how the example can be rewritten to get correct results for both
>   "tex" and "pdftex".
> * And you should read the answer of Martin, perhaps it has not
>   yet hit the archives. He quotes the pdfTeX manual
>   (http://www.pdftex.org/):
>
> | - \pdfhorigin (dimension)
> | This parameter can be used to set the horizontal offset the
> | output box from the top left corner of the page. A value of 1
> | inch corresponds to the normal TeX offset.  This parameter is
> | read when pdfTeX starts shipping out a page to the pdf output.
> |
> | For standard purposes, this parameter should always be kept at 1
> | true inch. If you want to shift text on the page, use TeX's own
> | \hoffset primitive. To avoid surprises, after global
> | magnification has been changed by the \mag primitive, the
> | \pdfhorigin parameter should still be 1 true inch, e. g. by
> | typing \pdfhorigin=1 true in after issuing the \mag command. Or,
> | you can preadjust the \pdfhorigin value before typing \mag, so
> | that its value after the \mag command ends up at 1 true inch
> | again.

I'm sorry if I am dense here, but this seems to be saying just what I
was complaining about : that in order to make the simplest of TeX files
work, you have to add non-trivial amounts of code to them. I guess I
could not believe, and still can't, that we are really going to accept
that as inevitable.

> |
> | - \pdfvorigin (dimension)
> | This parameter is the vertical companion of \pdfhorigin, and the
> | notes above regarding \mag and true dimensions apply. Also keep
> | in mind that the TeX coordinate system starts in the top left
> | corner (downward), while pdf coordinates start at the bottom left
> | corner (upward).
>
> \magnification \magstep5
>
> \input ifpdf.sty
> \ifpdf
>   % required after global use of \magnification:
>   \pdfhorigin 1 true in
>   \pdfvorigin 1 true in
>   % example, setting for A4 paper:
>   \pdfpagewidth 210mm
>   \pdfpageheight 297mm
> \fi
>
> \parindent 0pt
> \topskip 0pt
> \hoffset -1 truein
> \voffset -1 truein
> The top
> \end
>
> And regarding the changes in pdfTeX, see the second answer of Martin:
>
> | 1.20a corrected this. See the thread at
> | http://www.ntg.nl/pipermail/ntg-pdf...ril/000485.html

I looked at that mail, and it did not seem to be saying that a bog
standard file such as the one I refer to will just work. If I am
misunderstanding, and I simply have a broken version of tetex (3.09)
please correct me.

From a users point of view, it is glaringly obvious that if one is
introducing a new feature such as \pdfhorigin and \pdfvorigin into
a system as well established as tex, you do it in such a way as not to
break existing documents. I don't know enough about the pdf codebase to
know how best to do so, but I am sure that it is possible. Instead of
telling users to introduce complicated TeX at the top of their document,
to correct what we see as errors in pdftex, the code itself should be
written so that it does not break with \magnification. Presumably at a
minimum one could redefine \magnification within pdftex such that it
resets your \pdforigins in the way that the above thread suggested the
authors ought to. The fix can be in pdftex not in documents. It ought to
be in pdftex.

Sorry to seem to be telling you what to do, but I think it is important
you hear from (moderately knowledgable) users that this new feature is
implemented in a way that is badly broken for plain TeX users.

Ian Hutchinson

Ian Hutchinson <hutch@hutchinson.belmont.ma.us> wrote:
 
>
> Dear Heiko: First, thanks for all the work you've done on pdftex. I, for

I am not the person that added and implemented this "new" feature.

> one truly appreciate it. But now, the "price for a new feature" is way
> too high. You've broken any prior document that uses \magnification and
> changes \hoffset.

No, this is wrong. Original TeX doesn't generate PDF.
And pdfTeX in DVI mode (tested with pdfTeX 1.30.4)
doesn't use \pdf{h,v}origin. Thus I cannot see that
compatibility is broken.

If old pdfTeX versions behave differently in PDF mode,
thus you should remember that pdfTeX is a program that
is developed. Fixing bugs and adding new features are
part of development.
 
>
> If I understand you right, you are saying that if I add some code at the
> top of the plain tex file I have given as an example, I can fix it.
> Undoubtedly that is true, but it is irrelevant to my point, which is
> that introducing new features into pdftex SHOULD NOT cause the most
> basic of tex documents to be incorrectly rendered in pdf.

Use pdfTeX in DVI mode. For PDF format you have to do much more
things:
* DVI format doesn't know about paper size, but this is required
for PDF format. Thus you *must* specify the paper size, either
explicitly or implicitly by a default configuration.
* For generating DVI, fonts don't need to be known, just the TFM
files must be present. But the recommendation for PDF format is
the inclusion of fonts. Thus documents break, if the fonts are not
available.
* ...

And the ifpdf stuff is just for convenience, the file can then be
processed with TeX, pdfTeX in DVI mode, and pdfTeX in PDF mode.

> If it is
> deliberate that this happens, I can only say that I think it is a
> terrible mistake. For years pdftex has done just what tex does with such
> files. Suddenly now, you are going to change it?!

Use DVI mode, or see below, how the plain format for PDF mode
can be fixed:
 
>
> I'm sorry if I am dense here, but this seems to be saying just what I
> was complaining about : that in order to make the simplest of TeX files

The "simplest" of TeX files doesn't use \magnification. The use of
\magnification is asking for great trouble, it makes the life very
complicate:
* doubling of units by "true" key word.
* timing problems: assignments before and after changing of
\magnification (the problem of your example).

> work, you have to add non-trivial amounts of code to them.

You are using:

\hoffset -1 truein
\voffset -1 truein

Adding

\pdfhorigin 1 true in
\pdfvorigin 1 true in

after the \magnification setting is "non-trivial"?

> I guess I
> could not believe, and still can't, that we are really going to accept
> that as inevitable.

Now you have the chance to get rid of the nasty origin setting.
Put this into the format:

\pdfhorigin0pt
\pdfvorigin0pt

Then you can simplify your "simplest" example:

\magnification \magstep5
\parindent0pt
\topskip0pt
The top
\end

Nice, isn't it?
 
>
> I looked at that mail, and it did not seem to be saying that a bog
> standard file such as the one I refer to will just work. If I am
> misunderstanding, and I simply have a broken version of tetex (3.09)
> please correct me.

I don't know, which versions of pdfTeX you are using, I am using
version 1.30.4.

>  From a users point of view, it is glaringly obvious that if one is
> introducing a new feature such as \pdfhorigin and \pdfvorigin into
> a system as well established as tex, you do it in such a way as not to
> break existing documents.

Then never update your system. Otherwise it would be impossible to
add *any* new primitive. There could be a document that is accidently
using a macro with the same name, ...

> I don't know enough about the pdf codebase to
> know how best to do so, but I am sure that it is possible. Instead of
> telling users to introduce complicated TeX at the top of their document,

What is complicate? The *most* complicate part I can see is
\magnification \magstep5

> to correct what we see as errors in pdftex, the code itself should be
> written so that it does not break with \magnification. Presumably at a
> minimum one could redefine \magnification within pdftex such that it
> resets your \pdforigins in the way that the above thread suggested the
> authors ought to. The fix can be in pdftex not in documents. It ought to
> be in pdftex.

I disagree. \magnification is a user macro, defined in plain.tex.
And as plain TeX user it should be easy for you to change the
definition and add the \pdf*origin settings to your needs.

Put this into your plain format for generating PDF files with pdfTeX:

 \expandafter\def\expandafter\m@g\expanda
fter{%
\m@g
\pdfhorigin 1 true in%
\pdfvorigin 1 true in%
% Also correction of \pdfpagewidth and \pdfpageheight
% is a good idea.
}%

With correction of \pdfpage{width,height}:

 \expandafter\def\expandafter\m@g\expanda
fter{%
\m@g
\pdfhorigin 1truein%
\pdfvorigin 1truein%
\mag@fix\pdfpagewidth
\mag@fix\pdfpageheight
}
\def\mag@fix#1{%
 #1=\expandafter\convert@truept\the#1\rel
ax
}
\begingroup
\catcode`P=12
\catcode`T=12
\lowercase{%
\endgroup
\def\convert@truept#1PT{%
#1truept%
}%
}%

By the way, you know, that \hsize, \vsize, and \footins
are overwritten by \magnification?

> Sorry to seem to be telling you what to do, but I think it is important
> you hear from (moderately knowledgable) users that this new feature is
> implemented in a way that is badly broken for plain TeX users.

If you are using PDF mode, then you have to respect the requirements
of this mode. Setting of \pdfpagewidth and \pdfpageheight do belong to
them and also setting of \pdf{h,v}origin, if \mag(nification) is used.
And there are other (optional) things:
* Information entries (title, author, ...)
* Bookmarks
* Links
* ...

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

Heiko Oberdiek wrote:
>
>
> No, this is wrong. Original TeX doesn't generate PDF.
> And pdfTeX in DVI mode (tested with pdfTeX 1.30.4)
> doesn't use \pdf{h,v}origin. Thus I cannot see that
> compatibility is broken.
>
> If old pdfTeX versions behave differently in PDF mode,
> thus you should remember that pdfTeX is a program that
> is developed. Fixing bugs and adding new features are
> part of development.

Now I feel your replies are deliberately being obtuse. Let me specify
the issue I care about :

I want files written in TeX to be processable by tex itself to produce
dvi and ps files, and by pdftex to produce pdf, AND I want them to
produce the same layout for all forms.

This used to be the case, through the pdftex versions included in tetex
versions 1 and 2. The "new feature" introduced into the pdftex in
tetex-3 has broken this compatibility. Moreover it means that the new
pdftex cannot process correctly legacy documents that use \magnification
to produce compatible pdf from them.
 
>
>
> Use pdfTeX in DVI mode. For PDF format you have to do much more
> things:

You are deliberately muddying the waters to say that pdftex can produce
dvi from those legacy documents compatibly. That's irrelevant. Why
should anyone rely on pdftex to do what tex does fine? What is at issue
is whether compatible pdf is produced.
 
>
>
> Use DVI mode,
Don't keep saying that. It is deliberately confusing the point.

> or see below, how the plain format for PDF mode can be fixed:
 
>
>
> The "simplest" of TeX files doesn't use \magnification. The use of
> \magnification is asking for great trouble, it makes the life very
> complicate:
> * doubling of units by "true" key word.
> * timing problems: assignments before and after changing of
>   \magnification (the problem of your example).
>

Perhaps you have never used plain tex for authoring documents. If you
had, you would realize that almost every plain tex document uses
\magnification. A tiny fraction of plain tex documents are adequate
without it.

Your complaint about my using the expression the "simplest" is pure
lawyer talk. Again you are deliberately confounding the discussion. I am
tempted to think that is because you know my arguments are strong.
 
> 
>
>
> Then never update your system. Otherwise it would be impossible to
> add *any* new primitive. There could be a document that is accidently
> using a macro with the same name, ...
>

This comment is so ridiculous that I don't think you can mean it. Of
course every time someone upgrades a system there is an important
consideration of backward compatibility. If that were not so, you might
as well argue that the new pdftex has nothing to do with the old one or
with tex itself. Just wipe from your memory anything you ever knew about
tex, and from your hard disk all your legacy documents. Or at least
don't expect the "new" pdftex to give you from them what you had before.
Of course, there's a trade-off here. I am just telling you that the
authors of the latest version of pdftex have (IMHO) made a serious error
of judgement from a user's viewpoint. They have broken compatibility
with most plain tex documents.

This is most definitely not a peripheral matter. I care deeply about TeX
because it is by far the best system for authoring and publishing
mathematics, and because it is open. TeX does not pander to the
expectations of spoon-fed wysiwig expectations, but it still needs to be
incorporated in stable and usable systems to maintain its user base. If
users find that the famed stability of TeX is undermined for the
production of pdf, that hurts TeX and TeX users. You've got to realize
that TeX needs to appeal to people who are not TeX experts.

> 
>
>
> I disagree. \magnification is a user macro, defined in plain.tex.

No; it is part of the plain format and goes into the .fmt file. It is
therefore not a "user" macro, in any meaningful sense, and should not
have to be "fixed" by tex authors who want to use plain.

> And as plain TeX user it should be easy for you to change the
> definition and add the \pdf*origin settings to your needs.
>
> Put this into your plain format for generating PDF files with pdfTeX:

Now here I think we are getting to something that might be a way
forward. But it is not into the plain format that this should go, I
think, since that is what tex uses. It should go into the pdftex format
file. Actually on tetex, the pdftex.ini file is just

\pdfoutput=1
\input plain
\dump
\endinput

This would in fact be the sensible place to make whatever adjustments to
pdftex's format are needed to ensure that it can compatibly render plain
tex files.

>
>    \expandafter\def\expandafter\m@g\expanda
fter{%
>     \m@g
>     \pdfhorigin 1 true in%
>     \pdfvorigin 1 true in%
>     % Also correction of \pdfpagewidth and \pdfpageheight
>     % is a good idea.
>   }%
>
> With correction of \pdfpage{width,height}:
>
>  \expandafter\def\expandafter\m@g\expanda
fter{%
>   \m@g
>   \pdfhorigin 1truein%
>   \pdfvorigin 1truein%
>   \mag@fix\pdfpagewidth
>   \mag@fix\pdfpageheight
> }
> \def\mag@fix#1{%
>    #1=\expandafter\convert@truept\the#1\rel
ax
> }
> \begingroup
>   \catcode`P=12
>   \catcode`T=12
> \lowercase{%
>   \endgroup
>   \def\convert@truept#1PT{%
>     #1truept%
>   }%
> }%
>
> By the way, you know, that \hsize, \vsize, and \footins
> are overwritten by \magnification?

So perhaps now we have agreement? The pdftex.ini file should be editted
so as to put these redefinitions after the \input of plain. That way,
pdftex will work correctly, and transparently on documents which use
\magnification.

Is this something that the pdftex team should maintain, or do we need to
bring Thomas Esser (tetex mastermind) into the discussion.

Ian Hutchinson

Ian Hutchinson wrote:
> Heiko Oberdiek wrote:

<good points and talking at cross purposes snipped>


> This is most definitely not a peripheral matter. I care deeply about TeX
> because it is by far the best system for authoring and publishing
> mathematics, and because it is open. TeX does not pander to the
> expectations of spoon-fed wysiwig expectations, but it still needs to be
> incorporated in stable and usable systems to maintain its user base. If
> users find that the famed stability of TeX is undermined for the
> production of pdf, that hurts TeX and TeX users. You've got to realize
> that TeX needs to appeal to people who are not TeX experts.

I'm completely with Ian on this.  His problem is that when pdfTeX
generates PDF, the page layout is not the same as when it is used
to generated dvi - or when TeX is used to generate dvi from the same
source.

This \uppercase{should not happen}.


> Now here I think we are getting to something that might be a way
> forward. But it is not into the plain format that this should go, I
> think, since that is what tex uses. It should go into the pdftex format
> file. Actually on tetex, the pdftex.ini file is just
>
> \pdfoutput=1
> \input plain
> \dump
> \endinput
>
> This would in fact be the sensible place to make whatever adjustments to
> pdftex's format are needed to ensure that it can compatibly render plain
> tex files.

<snip>

> So perhaps now we have agreement? The pdftex.ini file should be editted
> so as to put these redefinitions after the \input of plain. That way,
> pdftex will work correctly, and transparently on documents which use
> \magnification.
>
> Is this something that the pdftex team should maintain, or do we need to
> bring Thomas Esser (tetex mastermind) into the discussion.

Again, I'm completely with Ian on this.  TeX is archival.  And I'm sure
this pdfeTeX wishes to be archival also.

--
Jonathan

Ian Hutchinson <hutch@hutchinson.belmont.ma.us> wrote:

> I want files written in TeX to be processable by tex itself to produce
> dvi and ps files, and by pdftex to produce pdf, AND I want them to
> produce the same layout for all forms.

I have already explained it and given code to achive this goal.

> This used to be the case, through the pdftex versions included in tetex
> versions 1 and 2. The "new feature" introduced into the pdftex in
> tetex-3 has broken this compatibility. Moreover it means that the new
> pdftex cannot process correctly legacy documents that use \magnification
> to produce compatible pdf from them.

* Why don't you say, which pdfTeX versions you are talking about?
I don't have tetex 1 and 2 installed.
* Do the versions support \pdfhorigin and \pdfvorigin at all?
* You should read the threads in the ntg-pdftex mailing list around
April 2004, e.g. "\magnification once more".
It seems the consensus was that the behaviour before 1.20a was
wrong. Thus you forbid bug fixes.
 
>
> You are deliberately muddying the waters to say that pdftex can produce
> dvi from those legacy documents compatibly. That's irrelevant. Why
> should anyone rely on pdftex to do what tex does fine? What is at issue
> is whether compatible pdf is produced.

I have already explained that if you use PDF mode there are
four registers you have to take care of:
\pdfpagewidth, \pdfpageheight
\pdfhorigin, \pdfvorigin
They are not used in DVI mode. It is so difficult to understand?
The DVI format doesn't know anything about page sizes, but
the PDF format requires the setting of the page dimensions.
 
> 
>
> Perhaps you have never used plain tex for authoring documents. If you
> had, you would realize that almost every plain tex document uses
> \magnification. A tiny fraction of plain tex documents are adequate
> without it.

There are much more powerful formats in the TeX world. Why should I
use one of the bad ones?

If you need \magnification for normal typeset documents (books,
articles, ..., but not posters or slides), then this indicates
serious problems.
* It is a difference to typeset a font at the intended size or using
scaled fonts. With the same height the width is usually different.
With \magnification (\mag <> 1000) you generate bad typography.
* The plain format doesn't provide a user friendly interface for the
font setup and setup of layout parameters. You need many lines
of code to get it right.

Thus the conclusion is that \magnification is useful in rare cases
only, perhaps for posters or slides.

>   Of course, there's a trade-off here. I am just telling you that the
> authors of the latest version of pdftex have (IMHO) made a serious error
>   of judgement from a user's viewpoint. They have broken compatibility
> with most plain tex documents.

You have not even shown that compatibility is broken. You run into a
bug in old versions. Correct is to reset some values after a
magnification change, also plain does this vor \hsize, \vsize, and
\footins. In PDF mode this list should be extended by \pdfpagewidth,
\pdfpageheight, \pdfhorigin, \pdfvorigin. Appearently you have
forgotten this. But why should pdfTeX keep compatibility for
errorneous documents?

My example

\magnification\magstep 1

\pdfpagewidth=210truemm
\pdfpageheight=297truemm
\pdfhorigin=1truein
\pdfvorigin=1truein

\hoffset=-1truein
\voffset=-1truein
\topskip=0pt
\parindent=0pt
The Top.
\end

works fine for old and new pdfTeX versions. And I have shown you fixes
to the plain format, that even the errorneous documents will work.

> You've got to realize that TeX needs to appeal to people who are not TeX experts.[
/color]

You contradict yourself, plain-TeX is not a format that I would
consider for people that are not TeX experts. Some lines above
I have shown you, that your favourite use of \magnification needs
some deep knowledge of what is going on. And I have expressed
my suscipion that you misuse this feature.
 
>
> No; it is part of the plain format and goes into the .fmt file.

A macro remains a macro, even it is put into the .fmt file. You should
read "The TeXbook".

> It is
> therefore not a "user" macro, in any meaningful sense, and should not
> have to be "fixed" by tex authors who want to use plain.

In contrary, most authors must change many macros of plain-TeX,
especially the macros that are responsible for layout. Haven't you
read "The TeXbook" or similar book? It even explains to change
the output routine. As user of plain-TeX you must be a TeX expert
in many cases for layout stuff that can be done in a trivial way
with other more powerful formats.
 
>
> Now here I think we are getting to something that might be a way
> forward. But it is not into the plain format that this should go,

You misunderstood me. I am not saying to change plain.tex.
I am meaning the format that you want to use for your pdfTeX
files in plain format.

> I think, since that is what tex uses. It should go into the pdftex format
> file. Actually on tetex, the pdftex.ini file is just
>
> \pdfoutput=1
> \input plain
> \dump
> \endinput
>
> This would in fact be the sensible place to make whatever adjustments to
> pdftex's format are needed to ensure that it can compatibly render plain
> tex files.

I agree.
 
>
> So perhaps now we have agreement? The pdftex.ini file should be editted
> so as to put these redefinitions after the \input of plain. That way,
> pdftex will work correctly, and transparently on documents which use
> \magnification.

Finally we agree here.

> Is this something that the pdftex team should maintain, or do we need to
> bring Thomas Esser (tetex mastermind) into the discussion.

Sorry I disagree again. You want to have the origin at 1in,1in in
any case. But there can be plain-TeX users that take the
opportunity to break compatibility and set the origin at 0in,0in
and perform their own clean margin calculations without being
bothered by the annoying shift of 1in. But it is difficult to write
clearvoyant code.

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

Jonathan Fine <jfine@pytex.org> wrote:

> Ian Hutchinson wrote:

> I'm completely with Ian on this.  His problem is that when pdfTeX
> generates PDF, the page layout is not the same as when it is used
> to generated dvi - or when TeX is used to generate dvi from the same
> source.
>
> This \uppercase{should not happen}.

Then explain what is the page size of the single pages of a DVI file.
The page size (/MediaBox) is a required part of the PDF format.
You want to have the same "page layout". IMHO the page size
belong to "page layout".

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