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 -----------------------------------------------------------------