pdftex broken in tetex-3: offsets incorrect
Ian Hutchinson
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
Morten Høgholm
wrote:
See the messages starting at
<http://www.ntg.nl/pipermail/ntg-pdftex/2006-January/001987.html>.
--
Morten
Ian Hutchinson
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
Heiko Oberdiek
> Morten Høgholm wrote:
> > On Sat, 28 Jan 2006 03:08:47 +0100, Ian Hutchinson <ihu...@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-pdftex/2006-January/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.
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-pdftex/2004-April/000485.html
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Ian Hutchinson
> Ian Hutchinson <hu...@hutchinson.belmont.ma.us> wrote:
>>Morten Høgholm wrote:
>>
>>>On Sat, 28 Jan 2006 03:08:47 +0100, Ian Hutchinson <ihu...@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
>>>See the messages starting at
>>><http://www.ntg.nl/pipermail/ntg-pdftex/2006-January/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.
>
>
> 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.
>>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.
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.
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
Heiko Oberdiek
> > 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
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.
> >>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.
> >
> > * 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.
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:
> > * 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
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?
> > 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-pdftex/2004-April/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.
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\expandafter{%
\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\expandafter{%
\m@g
\pdfhorigin 1truein%
\pdfvorigin 1truein%
\mag@fix\pdfpagewidth
\mag@fix\pdfpageheight
}
\def\mag@fix#1{%
#1=\expandafter\convert@truept\the#1\relax
}
\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 <ober...@uni-freiburg.de>
Ian Hutchinson
>
>
> 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.
>>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:
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.
>>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,
Don't keep saying that. It is deliberately confusing the point.
> 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).
>
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.
>>I guess I
>>could not believe, and still can't, that we are really going to accept
>>that as inevitable.
>
>> 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, ...
>
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.
>
>>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.
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.
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
Jonathan Fine
> 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
Heiko Oberdiek
> 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.
> > 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.
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.
> > 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).
> >
>
> 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.
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.
> >>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.
>
> 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.
> > 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,
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.
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 <ober...@uni-freiburg.de>
Heiko Oberdiek
> 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 <ober...@uni-freiburg.de>
Jonathan Fine
> Ian Hutchinson <hu...@hutchinson.belmont.ma.us> wrote:
<snip>
>>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?
Heiko, there are some good points in what you say.
However, 'more powerful' does not alway mean 'better'.
Software bloat arises from the addition of features.
To describe plain TeX as 'bad' is needlessly divisive, and
therefore damaging to out community.
Heiko, you have a good understanding the technical issues, and
make some good points. But saying plain TeX is 'bad' makes it
harder to others to see these merits.
--
Jonathan
Jonathan Fine
Heiko, as I understand it, Ian was saying that pdfetex generating
PDF used to behave in one way, in this respect, and now behaves
in another. And also that the previous was, effectively, the same
as TeX generating dvi.
Heiko, is my understanding of Ian correct, in your view? And, again
in my view, has Ian correctly stated the existence of a problem?
If so, then I'm still with Ian. An extension has been made, that
is not backwards compatible.
--
Jonathan
Sanjoy Mahajan
> There are much more powerful formats in the TeX world. Why should I
> use one of the bad ones?
'Bad' and 'good' are adjectives of taste. I loathe LaTeX because of
its vastness and I prefer the fine control, stability, and
reproducibility that I get with plain TeX (with eplain for
crossreferences). Plain TeX is clean and simple enough for me to have
a mental model of it, which makes programming and using it enjoyable
_for me_. Others loathe the fine details that you have to worry about
(e.g. numbering footnotes), and prefer LaTeX or have to use it because
a journal requires it.
Let each use what he or she prefers.
In earlier version of pdftex, the margins came out the same as when
running (dvi) tex. With version 1.30a they do not, and this change is
not backwards compatible. If fixing a serious bug or adding a vital
feature requires breaking backwards compatability, so be it: It's a
necessary evil. But breaking backwards compatability should be
avoided, even for users of a format that others think is inferior.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Heiko Oberdiek
> Heiko, as I understand it, Ian was saying that pdfetex generating
> PDF used to behave in one way, in this respect, and now behaves
> in another. And also that the previous was, effectively, the same
> as TeX generating dvi.
Sorry Jonathan, please read what I have written as answers to Ian.
I you don't understand it, thus I cannot help you here further.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek wrote:
> > There are much more powerful formats in the TeX world. Why should I
> > use one of the bad ones?
> However, 'more powerful' does not alway mean 'better'.
The point is, that essential features are missing in plain-TeX, eg.
a good interfaces for font setup, layout setup, ...
> Software bloat arises from the addition of features.
That's not the point here.
> To describe plain TeX as 'bad' is needlessly divisive, and
> therefore damaging to out community.
I feel with you, hearing the truth isn't always a pleasure.
> Heiko, you have a good understanding the technical issues, and
> make some good points. But saying plain TeX is 'bad' makes it
> harder to others to see these merits.
About twenty years ago (you know better than me, when
plain.tex was written and its development had stopped).
A lot has happened since. And I believe that it is
in the sense of the master that people have worked with his
masterpiece and have developed new formats that fits the
requirements of the current time better.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> wrote:
> > There are much more powerful formats in the TeX world. Why should I
> > use one of the bad ones?
>
> 'Bad' and 'good' are adjectives of taste.
It is a little bit provocative.
> I loathe LaTeX because of
> its vastness and I prefer the fine control, stability, and
> reproducibility that I get with plain TeX (with eplain for
> crossreferences).
Then plain TeX also isn't "good" enough for you, because you
have choosen a format that extends the possibilities of
plain-TeX.
On purpose I haven't meantioned any of the other formats,
because I know many other exist, LaTeX and eplain are just
two of them.
> In earlier version of pdftex, the margins came out the same as when
> running (dvi) tex. With version 1.30a they do not, and this change is
> not backwards compatible. If fixing a serious bug or adding a vital
> feature requires breaking backwards compatability, so be it: It's a
> necessary evil. But breaking backwards compatability should be
> avoided, even for users of a format that others think is inferior.
Bugs or bad design are other evil things. What's the point about
complaining about backwards compatibility? It is not the decision
of the author/maintainer/developers of pdfTeX, which evil they
want to choose?
Nobody in this thread has proven, that backwards compatibility
is indeed violated, if backwards compatibility is not meant to apply
on errorneous input:
\magnification (\mag <> 1000) changes the scaling of the
coordinate system. Previous length that are set with the
assumption of unscaled coordinate system are now wrong.
Thus it should be not a surprise that these lengths need fixing.
And if this fixing is missing the input is wrong. And if the result
happens to be correct nevertheless, you just have luck.
And if the bug is fixed in later versions and the result of the
errorneous input becomes wrong, then you are just out of luck.
My assumption is that this happened here with \pdf{h,v}origin,
see the clues I posted earlier, but I haven't the time for a deeper
search of historical pdfTeX versions and analyzing them.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
> Sanjoy Mahajan <san...@mrao.cam.ac.uk> wrote:
<snip>
>>In earlier version of pdftex, the margins came out the same as when
>>running (dvi) tex. With version 1.30a they do not, and this change is
>>not backwards compatible. If fixing a serious bug or adding a vital
>>feature requires breaking backwards compatability, so be it: It's a
>>necessary evil. But breaking backwards compatability should be
>>avoided, even for users of a format that others think is inferior.
>
> Bugs or bad design are other evil things. What's the point about
> complaining about backwards compatibility? It is not the decision
> of the author/maintainer/developers of pdfTeX, which evil they
> want to choose?
I'm with Sanjoy on this. And if backwards compatibility is broken,
this should be clearly stated in the new release, along with work
arounds.
We form a community. Lack of backwards compatibility can divide
that community. And lack of development can stagnate the community.
Both the developers and users of pdftex have decisions to make. And
a dialog betweent the two is very important for the strength of the
community.
> Nobody in this thread has proven, that backwards compatibility
> is indeed violated, if backwards compatibility is not meant to apply
> on errorneous input:
Ian Hutchinson, in the original post to this thread, 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.
===
Are you saying, Heiko, that this input is erroneous? Or that it is
rendered correctly by pdfetex?
Hint. In your response to this you 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.
===
To me, Heiko, this sounds like you have admitted that backwards
compatibility has been violated.
BTW, TeX does not place the origin at a 'random place'. It may not
be where you wish, but it always does the same thing.
BTW, when you write 'original TeX', the 'original' is redundant.
--
Jonathan
Heiko Oberdiek
> Heiko Oberdiek wrote:
> Ian Hutchinson, in the original post to this thread, 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.
> ===
>
> Are you saying, Heiko, that this input is erroneous? Or that it is
> rendered correctly by pdfetex?
For pdfTeX in PDF mode you have to fix it, see my previous posts.
> Hint. In your response to this you 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.
> ===
>
> To me, Heiko, this sounds like you have admitted that backwards
> compatibility has been violated.
Compatibility to what? Since when does original TeX generate PDF?
And for pdfTeX in PDF mode, nobody has shown yet, that compatibility
is violated.
> BTW, TeX does not place the origin at a 'random place'.
A natural choice would be one of the corners of the page,
preferable the left ones. Choosing "1in,1in" is *random*.
> BTW, when you write 'original TeX', the 'original' is redundant.
No, it isn't.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
news:drkrli$2nk$1...@news.BelWue.DE...
> Jonathan Fine <jf...@pytex.org> wrote:
> > To me, Heiko, this sounds like you have admitted that backwards
> > compatibility has been violated.
>
> Compatibility to what? Since when does original TeX generate PDF?
> And for pdfTeX in PDF mode, nobody has shown yet, that compatibility
> is violated.
==
$ pdfetex
This is pdfeTeX, Version 3.141592-1.11b-2.1 (MiKTeX 2.4)
**\magnification \magstep5
entering extended mode
{pdftex.cfg}
*\parindent 0pt
*\hoffset -1 truein
*\voffset -1 truein
*The top
*\end
[1{psfonts.map}{winfonts.map}]<cmr10.pfb>
Output written on texput.pdf (1 page, 6928 bytes).
Transcript written on texput.log.
==
When I run this, the words 'The top' are at the top left of
the page. And the same when I use TeX instead.
So the 'old' pdfetex is compatible, in this respect, with
TeX.
But, it seems, with the new pdfetex, the words 'The top' are
placed somewhere else. (I don't have the new one to hand.)
If so, then the new pdfetex is incompatible, in this
respect, with both TeX and the old pdfetex.
--
Jonathan
Heiko Oberdiek
> $ pdfetex
> This is pdfeTeX, Version 3.141592-1.11b-2.1 (MiKTeX 2.4)
> **\magnification \magstep5
% Your forgot in PDF mode:
\pdfhorigin 1truein
\pdfvorigin 1truein
\pdfpagewidth 210truemm % or whatever
\pdfpageheight 297truemm % or whatever
This thread is a very good example for wasting resources in
discussion about the very bad and annoying design decision,
to put the origin somewhere in the page and not to have an
idea of a page size.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Ian Hutchinson
> Ian Hutchinson <hu...@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.
[Misunderstanding and obfuscation cut]
>>>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.
>
>
> I agree.
WONDERFUL!!
>>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.
Phew! That's great!
>
>
>>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.
But you just agreed!
> 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.
>
Again, I want, and everyone else wants, backward compatibility. It's
great that you are giving us ALSO the ability to do things in what you
consider to be a better way. But you see there is a way to do that
WITHOUT breaking backward compatibility.
All we need to do now is to get whomever is responsible for the
pdftex.ini code to agree that it should be modified for the latest
version of pdftex. Is that you? Or is it Thomas Esser and other TeX
package maintainers?
Ian Hutchinson.
Heiko Oberdiek
> > 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.
> >
>
> Again, I want, and everyone else wants, backward compatibility. It's
> great that you are giving us ALSO the ability to do things in what you
> consider to be a better way. But you see there is a way to do that
> WITHOUT breaking backward compatibility.
I have just given you a suggestion that would (probably) fit *your*
needs very well. But there can be other people, that have other
needs. Perhaps they put the origin at 0pt,0pt on purpose.
Well, this can be fixed by this:
\expandafter\def\expandafter\m@g\expandafter{%
\m@g
\mag@fix\pdfhorigin
\mag@fix\pdfvorigin
\mag@fix\pdfpagewidth
\mag@fix\pdfpageheight
}
\def\mag@fix#1{%
#1=\expandafter\convert@truept\the#1\relax
}
\begingroup
\catcode`P=12
\catcode`T=12
\lowercase{%
\endgroup
\def\convert@truept#1PT{%
#1truept%
}%
}%
But why do you know, that people that set \pdf{h,v}origin and
\pdfpage{width,height} to other values than zero, want these
values fixed after changing of \mag? It is possible that they don't
*want* to scale these values according to the setting of \mag.
This is one of the disadvantages of \mag, you generate two
coordinate systems, for each length the layouter must decide
which system the length belong to. Welcome to the hell of \mag.
Therefore a code that fulfils the wishes of all people must be
clairvoyant.
> All we need to do now is to get whomever is responsible for the
> pdftex.ini code to agree that it should be modified
Put your modified pdftex.ini in your local or home texmf tree or
whereever and be happy.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Ian Hutchinson
>
>>>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.
>>>
>>
>>Again, I want, and everyone else wants, backward compatibility. It's
>>great that you are giving us ALSO the ability to do things in what you
>>consider to be a better way. But you see there is a way to do that
>>WITHOUT breaking backward compatibility.
>
>
> I have just given you a suggestion that would (probably) fit *your*
> needs very well. But there can be other people, that have other
> needs. Perhaps they put the origin at 0pt,0pt on purpose.
> But why do you know, that people that set \pdf{h,v}origin and
> \pdfpage{width,height} to other values than zero, want these
> values fixed after changing of \mag? It is possible that they don't
> *want* to scale these values according to the setting of \mag.
> This is one of the disadvantages of \mag, you generate two
> coordinate systems, for each length the layouter must decide
> which system the length belong to. Welcome to the hell of \mag.
> Therefore a code that fulfils the wishes of all people must be
> clairvoyant.
No we do not need clairvoyance. We simply need backwards compatibility.
If the origin is reset to where it has been for the past twenty five
years by default, then anyone who wants it somewhere else it their new
files can put it there perfectly well by adding their own code to those
files.
What is totally stupid is to put it somewhere new, which is what the
unpatched latest pdftex does; so that every old file that uses the
\magnification macro (which as I have explained to you is a high
fraction of all plain tex files) is broken as far as pdf production is
concerned.
Since you have already heaped criticism on people who use
\magnification, telling us we should not do so, changes to it in the
pdftex.ini won't affect anything that you think should be used. There
simply is no reason not to fix \magnification for people who want it and
have used it for the history of TeX, and to do it in the pdftex.ini.
You've told me again and again how easy it is to fix this problem. Why
not do so properly as we've been discussing. You'll preserve the
integrity of TeX using the plain format and outputing pdf, and prevent
endless difficulty for users. Do you just enjoy the fact that you've
made these difficulties for users? Or do you not surely want pdftex to
be as valuable as it can be?
>
>
>>All we need to do now is to get whomever is responsible for the
>>pdftex.ini code to agree that it should be modified
>
>
> Put your modified pdftex.ini in your local or home texmf tree or
> whereever and be happy.
>
Do you actually not know who has responsibility for the standard
pdftex.ini file? If you don't know, why not just say so. If it is the
pdftex folks such as yourself, what benefit is there to continued
obstructionism? [No, don't answer me, I know you'll have some sort of
answer. That was just rhetorical.]
Ian Hutchinson
Samuel Hornus
Ian Hutchinson <hu...@hutchinson.belmont.ma.us> wrote:
> Do you actually not know who has responsibility for the standard
> pdftex.ini file?
Why don't you try to contact the author(s) of pdfTeX ?
[Hint : http://www.tug.org/applications/pdftex/README]
--
Sam
Robin Fairbairns
he already has done. indeed, posting here seems to have been second
(or even third) thoughts.
--
Robin Fairbairns, Cambridge
Heiko Oberdiek
AFAIK, the author of pdfTeX is not responsible for pdftex.ini.
I don't know why it is so difficult to look for the Copyright notice
inside the file.
Yours sincerely
Heiko <ober...@uni-freiburg.de>