Bug in pdftex. Fixed by attached pdftex.ini.
---------- Forwarded message ---------- Date: Fri, 10 Feb 2006 23:07:36 -0500 (EST) From: hutch@psfc.mit.edu To: tetex@dbs.uni-hannover.de Subject: Bug in pdftex. Fixed by attached pdftex.ini In tetex-3... pdftex has a serious bug. Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \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% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson http://www.psfc.mit.edu/people/hutch/
On Fri, 10 Feb 2006 hutch@psfc.mit.edu wrote:
%These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight
if this patch should be implemented at all (the current way is much cleaner and more intuitive, as e. g. \pdfhorigin is handled naturally like any other TeX dimension, after the description in the TeXbook) then one should not forget that the list is not complete: There is also \pdflinkmargin, \pdfdestmargin, and \pdfthreadmargin to be modified. Regards, Hartmut
On Sat, 11 Feb 2006, Hartmut Henkel wrote:
On Fri, 10 Feb 2006 hutch@psfc.mit.edu wrote:
%These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight
if this patch should be implemented at all (the current way is much cleaner and more intuitive, as e. g. \pdfhorigin is handled naturally like any other TeX dimension, after the description in the TeXbook) then one should not forget that the list is not complete: There is also \pdflinkmargin, \pdfdestmargin, and \pdfthreadmargin to be modified.
...and the sentence in the pdftex manual "Or, you can preadjust the \type{\pdfhorigin} value before typing \type{\mag}, so that its value after the \type{\mag} command ends up at 1~true inch again." would be wrong as then there would be a double-"correction". Any users having used this tip would wonder about suddenly wrong dimensions. I'll have to check my posters... Regards, Hartmut
On Sat, 11 Feb 2006, Hartmut Henkel wrote:
On Fri, 10 Feb 2006 hutch@psfc.mit.edu wrote:
%These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight
if this patch should be implemented at all (the current way is much cleaner and more intuitive, as e. g. \pdfhorigin is handled naturally like any other TeX dimension, after the description in the TeXbook) then one should not forget that the list is not complete: There is also \pdflinkmargin, \pdfdestmargin, and \pdfthreadmargin to be modified.
It is not clear to me that those extra dimensions need to be fixed, although it might be good. What is vital is that plain documents that don't have reference to pdftex dimensions should still render properly in pdf, as they used to do in earlier pdftex versions. The patch does not affect "the current way" at all, as far as I can see. It simply corrects erroneous values that arise when magnification is used because they have not been expressed in true units. It also won't affect latex documents which don't use the pdf[e]tex.ini formats.
...and the sentence in the pdftex manual
"Or, you can preadjust the \type{\pdfhorigin} value before typing \type{\mag}, so that its value after the \type{\mag} command ends up at 1~true inch again."
This "tip", is of course an acknowledgement that without the patch, pdftex has broken all plain tex files with magnification. The point of the patch is to remove the necessity for authors/users to worry about the fact that \magnification is broken: because then it isn't! So the manual should presumably simply drop the tip.
would be wrong as then there would be a double-"correction". Any users having used this tip would wonder about suddenly wrong dimensions. I'll have to check my posters...
Ian Hutchinson
Ian Hutchinson wrote:
It is not clear to me that those extra dimensions need to be fixed, although it might be good. What is vital is that plain documents that don't have reference to pdftex dimensions should still render properly in pdf, as they used to do in earlier pdftex versions.
The discussion on c.t.t. about this went along the same lines, and the main problem is that documents that use \magnification are inherently flawed. The DVI format (i.e. TeX) claims not to know about physical page dimensions; but at the same time it does allow you to shift and scale the content of the physical output plane. There is an inherent conflict there. Pdftex brings this in the spotlight because the PDF format does have a physical page, and its offsets needs to be specified. The magnification scaling stuff was nice when all we had was bitmapped fonts, but I believe anybody who still uses it in this day and age should be hit on the head with the PostScript or PDF specification (repeatedly). That said, I believe this patch is not really a bad idea, but one should change the formats name at the same time (it wouldnt be just plain.tex anymore) I thought these .ini files are maintained by the tex-live crew, btw? Cheers, Taco
On Sun, 12 Feb 2006, Taco Hoekwater wrote:
The discussion on c.t.t. about this went along the same lines, and the main problem is that documents that use \magnification are inherently flawed. The DVI format (i.e. TeX) claims not to know about physical page dimensions; but at the same time it does allow you to shift and scale the content of the physical output plane. There is an inherent conflict there. Pdftex brings this in the spotlight because the PDF format does have a physical page, and its offsets needs to be specified.
I don't know where you get the idea that dvi does not know anything about page dimensions. It is clearly quite erroneous. TeX itself does specify its offsets, and dvips etc specify their pages sizes in accordance with settings that need to be compatible with the extent of the text (i.e. \hsize, \vsize).
The magnification scaling stuff was nice when all we had was bitmapped fonts, but I believe anybody who still uses it in this day and age should be hit on the head with the PostScript or PDF specification (repeatedly).
This comment, like many from others, misses the point. TeX is an archival representation of scientific documents. That is a major strength. TeX is not just a computer tool for producing new documents. You undermine the value of TeX if you abandon for no reason backward compatibility. Your opinions or those of others about the advisability of using magnification for new documents are not the issue at hand. Nothing in the patch I have offered affects any document that follows your advice and does not use magnification. The patch simply fixes those that do use it, whether new or old. I won't argue with opinionated pronouncements about features of TeX that appear redundant or troublesome. I could make pronouncements of my own about other such features. However, I will continue to say loudly, that until a patch like this is applied, the latest version of pdftex has broken plain tex files for no good reason. That is a bad thing, and since the fix is so easy, it should be fixed ASAP.
That said, I believe this patch is not really a bad idea, but one should change the formats name at the same time (it wouldnt be just plain.tex anymore)
The format I have proposed to patch is not plain, but pdftex.ini. The plain.fmt never enters into consideration. plain is not being patched. A pdftex-specific file is being patched. Ian Hutchinson
Ian Hutchinson wrote:
On Sun, 12 Feb 2006, Taco Hoekwater wrote:
The discussion on c.t.t. about this went along the same lines, and the main problem is that documents that use \magnification are inherently flawed. The DVI format (i.e. TeX) claims not to know about physical page dimensions; but at the same time it does allow you to shift and scale the content of the physical output plane. There is an inherent conflict there. Pdftex brings this in the spotlight because the PDF format does have a physical page, and its offsets needs to be specified.
I don't know where you get the idea that dvi does not know anything about page dimensions. It is clearly quite erroneous. TeX itself does specify its offsets, and dvips etc specify their pages sizes in accordance with settings that need to be compatible with the extent of the text (i.e. \hsize, \vsize).
your claim does not stand; as taco says, *dvi* does not know about page dimensions, unless you've uncovered a new dvi opcode and page dimension related pure tex primitive it's dvips that deals with the page dimenions (and it understands specials that specify them, but specials are, well, specials, not part of the tex standard) pdftex being both frontend and backend has to deal with it and instead of relying on external configurations (like dvips) has more control built in from the perspective of tex (macro packages) such things are often more complex than simply defining a page, since one has to deal with page-on-page mapping as well as the reference point, in tex/dvi upper left corner and in pdf(tex) the lower left corner and therefore pdftex needs to know the page dimensions at runtime (and the offsets are just [compatibility] left overs) in the beginning pdftex didn't even support maginification and after it was implemented it went through several cycles of development because the results neded to be comparable to dvips output and controllable from the tex level (the problem with magnification is that in a dvi backend it only involves fonts and to be included graphics, while in pdftex it also involves annotations; in both situation it will probably break any literal code (ps/pdf) unless explicitly dealt with)
The magnification scaling stuff was nice when all we had was bitmapped fonts, but I believe anybody who still uses it in this day and age should be hit on the head with the PostScript or PDF specification (repeatedly).
This comment, like many from others, misses the point. TeX is an archival representation of scientific documents. That is a major strength. TeX is not just a computer tool for producing new documents. You undermine the value of TeX if you abandon for no reason backward compatibility. Your opinions or those of others about the advisability of using magnification for new documents are not the issue at hand. Nothing in the patch I have offered affects any document that follows your advice and does not use magnification. The patch simply fixes those that do use it, whether new or old.
apart from the fixing aspect, it's normally macro packages that deal with such matters, so if anything is broken, fix or extend the macro package ... personally i don't even know what is in the ini files and i don't let my systems depend on it -) magnification is indeed kind of obsolete, as is dvi (which is not portable anyway since it lacks certain information and the last 25 years nobody bothered with extending it to carry more information around [like encodings or graphics] cq. it was impossible to reach an agreement on such extensions] the bug you mention is therefore more comparable to a (temporary) bug in dvips for the average tex user compatibility mostly means that one can still (maybe with small modifications) process old documents; magnification was never meant as a feature to be used for final prints, so if something fails in that area it does not break the compatibility story with regards to processing old sources i'd be more concerned about - changed hyphenation patterns - patches in the program (less and less) - patched macro code - changes in fonts - availability of additional resources
I won't argue with opinionated pronouncements about features of TeX that appear redundant or troublesome. I could make pronouncements of my own about other such features. However, I will continue to say loudly, that until a patch like this is applied, the latest version of pdftex has broken plain tex files for no good reason. That is a bad thing, and since the fix is so easy, it should be fixed ASAP.
well, if it's broken it will be repaired, what puzzles me is that nobody noticed this dureing the 'texlive code freeze', it looks like there are no plain tex users testing pdftex at that stage
That said, I believe this patch is not really a bad idea, but one should change the formats name at the same time (it wouldnt be just plain.tex anymore)
The format I have proposed to patch is not plain, but pdftex.ini. The plain.fmt never enters into consideration. plain is not being patched. A pdftex-specific file is being patched.
indeed, although i can imagine that the plain tex format could have a conditional section, doing those initializations; if we want certain code in there, we can propose it to dek (the web formatting code is also pdftex aware). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Mon, 13 Feb 2006, Hans Hagen wrote:
Ian Hutchinson wrote:
On Sun, 12 Feb 2006, Taco Hoekwater wrote: I don't know where you get the idea that dvi does not know anything about page dimensions. It is clearly quite erroneous. TeX itself does specify its offsets, and dvips etc specify their pages sizes in accordance with settings that need to be compatible with the extent of the text (i.e. \hsize, \vsize).
your claim does not stand; as taco says, *dvi* does not know about page dimensions, unless you've uncovered a new dvi opcode and page dimension related pure tex primitive
it's dvips that deals with the page dimenions (and it understands specials that specify them, but specials are, well, specials, not part of the tex standard)
I think you are just nit picking. Without dvi2something, the TeX system is incomplete. You say only the 'something' needs to know paper size. I say, of course, but \hsize has to be chosen with some knowledge of papersize, so tex and something have to be coordinated even when dvi is in use.
the bug you mention is therefore more comparable to a (temporary) bug in dvips
If it were just papersize, I would agree. When it is offsets as well, which TeX knows about, then I would argue it is somewhat more fundamental. But in any case, since pdftex is in a sense responsible for the work of the combination tex+dvips, it's comparable to a bug in pdftex.
for the average tex user compatibility mostly means that one can still (maybe with small modifications) process old documents; magnification was never meant as a feature to be used for final prints, so if something fails in that area it does not break the compatibility story
I totally disagree. What magnification is "meant for" is not just what one person or group of persons thinks. I believe this misunderstanding of the role in plain of \magnification is one reason why this bug has received such short shrift until now. Compatibility is compatibility.
However, I will continue to say loudly, that until a patch like this is applied, the latest version of pdftex has broken plain tex files for no good reason. That is a bad thing, and since the fix is so easy, it should be fixed ASAP.
well, if it's broken it will be repaired,
Excellent!
what puzzles me is that nobody noticed this dureing the 'texlive code freeze', it looks like there are no plain tex users testing pdftex at that stage
People did notice it, as you'll see if you go back through the mail archives (although admittedly not that many people). The problem was not properly diagnosed at the time (by my interpretation of the exchanges) and the complaints were treated with considerable disdain, which probably discouraged the pursuit of the problem. Not everyone is thick-skinned enough to overcome the aggressive tone of the pdftex croud. Regards, Ian Hutchinson.
On 2006-02-10 23:16:13 -0500, hutch@psfc.mit.edu wrote:
I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html
ANOTHER forum. :-( Is it so difficult to follow the instructions in the pdfTeX REDAME? Please, file a bug for this at sarovar; this will allow us to archive this discussion (\mag et.al) once. Please see also http://www.ntg.nl/pipermail/ntg-pdftex/2004-April/000487.html http://www.ntg.nl/pipermail/ntg-pdftex/2004-April/000488.html http://www.ntg.nl/pipermail/ntg-pdftex/2004-April/000489.html http://www.ntg.nl/pipermail/ntg-pdftex/2004-April/000492.html I think I understand your problem, but the pdfTeX team thinks that the current behaviour of pdfTeX (as it was up to 0.13d and is since 1.20a) is the correct one. Changing pdftex.ini should be done by the maintainers of TeX distribution (e.g. teTeX, MikTeX etc.); but that would probably break compatibility with newer documents. Best Martin -- http://www.tm.oneiros.de
On Sun, 12 Feb 2006, Martin [iso-8859-1] Schr�der wrote: .... [Sarcastic comment removed]
Please, file a bug for this at sarovar; this will allow us to archive this discussion (\mag et.al) once.
OK, done, since you insist.
I think I understand your problem, but the pdfTeX team thinks that the current behaviour of pdfTeX (as it was up to 0.13d and is since 1.20a) is the correct one.
No, as my report and original email make clear this bug is NOT present in version: pdfTeX (Web2C 7.4.5) 3.14159-1.10b, nor as far as I know any earlier versions.
Changing pdftex.ini should be done by the maintainers of TeX distribution (e.g. teTeX, MikTeX etc.); but that would probably break compatibility with newer documents.
No, it would break nothing in documents that don't use \magnification. Since the version of pdftex with this bug has only recently been included in TeX distributions, there are probably very few documents whose authors have been forced to introduce incompatible hacks to overcome it. The sooner it is fixed, though, the better. As far as where the fix should be introduced, IMHO, it would be better if the pdftex dimensions were all in true units, in which case this would never have arisen and the pdftex.ini file would not have to be patched like this. However, I sense that pdftex maintainers/developers wish to resist that, for their own reasons. If so, then patching pdftex.ini seems a reasonable compromise. Ian Hutchinson.
participants (6)
-
Hans Hagen -
Hartmut Henkel -
hutch＠psfc.mit.edu -
Ian Hutchinson
-
Martin Schröder -
Taco Hoekwater