[OS X TeX] pdftex paper size

Bruno Voisin bvoisin at mac.com
Fri May 19 04:03:30 EDT 2006

Le 19 mai 06 à 08:57, Ross Moore a écrit :

> \pdfpageheight and \pdfpagewidth  determine the size (when viewed  
> at 100%)
> of the picture of a page that is shown by a PDF browser.
> This *should* be the same as the \paperwidth  and \paperheight .

Hi Ross,

I think what you're seeing reflects that you're using a relatively  
old version of TeX (meaning here TeXLive or teTeX). The way things  
work in this respect has changed some time ago, there is no longer a  
pdftex.cfg and all is set for pdfTeX in pdftexconfig.tex which is  
handled differently. There was a thread "[tex-live] [Fwd: [OS X TeX]  
Bug in latest pdfTeX (and/or teTeX) with respect to \magnification?]"  
here in which Hartmut Henkel participated starting on 21 December  
2004. I'm not finding some of the messages from this thread on Gmane,  
hence I'm forwarding two of the messages from Hartmut at the end of  
this message.

> To check these values, try something like:
>    \documentclass[11pt,letter]{article}

Only works for me if I replace [letter] by [letterpaper]. Otherwise I  

LaTeX Warning: Unused global option(s):

>      \showthe\paperheight
>      \showthe\pdfpageheight
>      \showthe\paperwidth
>      \showthe\pdfpagewidth
>    \begin{document}
>      \showthe\pdfpageheight
>      \showthe\pdfpagewidth
> and watch the console window  (.log file).
> For me using TeXShop, I get:
> This is pdfeTeXk, Version 3.141592-1.11b-2.1 (Web2C 7.5.2)
> \write18 enabled.
> %&-line parsing enabled.
> (/usr/local/teTeX/share/texmf/web2c/cp8bit.tcx)
> (./tables.tex{/usr/local/teTeX/share/texmf-var/pdftex/config/ 
> pdftex.cfg}

This (the inclusion of pdftex.cfg) is what I think is causing what  
you're seeing.

> LaTeX2e <2001/06/01>
> Babel <v3.7h> and hyphenation patterns for english, dumylang,  
> nohyphenation, ge
> rman, ngerman, spanish, french, ukenglish, dutch, loaded.
> (/usr/local/teTeX/share/texmf/tex/latex/base/article.cls
> Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
> (/usr/local/teTeX/share/texmf/tex/latex/base/size11.clo))
> > 794.96999pt.
> l.3 \showthe\paperheight
> ?
> > 845.04694pt.
> l.4 \showthe\pdfpageheight
> ?
> > 614.295pt.
> l.5 \showthe\paperwidth
> ?
> > 597.50793pt.
> l.6 \showthe\pdfpagewidth
> ?
> ... so that it looks like for letter-paper there is
> a clear difference.
> But after \begin{document} has been reached, the PDF length
> values are altered...
> loading : Context Support Macros / Missing
> )
> loading : Context Support Macros / PDF
> )

Or are you loading here (between lines 6 and 29) some macros that  
would alter \pdfpageheight and \pdfpagewidth?

> > 794.96999pt.
> l.29 \showthe\pdfpageheight
> ?
> > 614.295pt.
> l.31 \showthe\pdfpagewidth
> ?
> ... giving perfect agreement.

That's not what I'm seeing (in TeXShop):

This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5)
\write18 enabled.
entering extended mode
LaTeX2e <2005/12/01>
Babel <v3.8d> and hyphenation patterns for american, british, french,  
german, n
german, dutch, italian, norsk, portuges, spanish, swedish,  
nohyphenation, loade
Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
 > 794.96999pt.
l.2      \showthe\paperheight

 > 845.04684pt.
l.3      \showthe\pdfpageheight

 > 614.295pt.
l.4      \showthe\paperwidth

 > 597.50787pt.
l.5      \showthe\pdfpagewidth

 > 845.04684pt.
l.7      \showthe\pdfpageheight

 > 597.50787pt.
l.8      \showthe\pdfpagewidth

(./moore.aux) )
No pages of output.
Transcript written on moore.log.

> [...]
> In other words: user beware.
> Check out what your packages are doing, and how they may interact
> to give (or spoil) the effects that you want to achieve.
> You are now going beyond what can be deduced from standard LaTeX
> usage and documentation.


Following are now the two messages from Hartmut, in which he explains  
why pdftex.cfg and the associated mechanism has been replaced by  
pdftexconfig.tex and the associated mechanism. Not that I understand  
perfectly all the technical details, nor that I agree with the  
choices made!



> De : Gerben Wierda
> Date : 21 décembre 2004 01:23:02 HNEC
> À : Bruno Voisin, TeX on Mac OS X Mailing List
> Objet : Réexp : [tex-live] [Fwd: [OS X TeX] Bug in latest pdfTeX  
> (and/or teTeX) with respect to \magnification?]
> I played post office with this question from Bruno:
> Begin forwarded message:
>> From: Hartmut Henkel
>> Date: 21 December 2004 01:16:00 GMT+01:00
>> To: Gerben Wierda
>> Cc: texlive
>> Subject: Re: [tex-live] [Fwd: [OS X TeX] Bug in latest pdfTeX (and/ 
>> or teTeX) with respect to \magnification?]
>> On Mon, 20 Dec 2004, Gerben Wierda wrote:
>>> I saw this message on the TeX on Mac OS X list. Not being a pdfTeX
>>> expert (I just redistribute) I wondered what is going on. Can  
>>> someone
>>> educate me?
>> will try... :-)
>>> G
>>> ---------------------------- Original Message  
>>> ----------------------------
>>> Subject: [OS X TeX] Bug in latest pdfTeX (and/or teTeX) with  
>>> respect to
>>> \magnification? From:    "Bruno Voisin"
>>> Date:    Mon, December 20, 2004 10:26
>>> To:      "TeX on Mac OS X Mailing List"
>>> -------------------------------------------------------------------- 
>>> ------
>>> Hello,
>>> I've just noticed something odd, when typesetting a letter in plain
>>> TeX for a change:
>>> - The setup is TL2004, installed via i-Installer with A4 selected as
>>> the default paper size.
>>> - When \magnification is not altered, in pdfTeX the paper size is A4
>>> as it should.
>>> - When \magnification is changed (for example
>>> \magnification=\magstep1), the page size (ie the width and height of
>>> text) remains A4 but the paper size (ie the size of the physcal  
>>> sheet
>>> of paper) is affected by the magnification.
>> The \magnification macro (not a primitive!) does not only set the
>> magnification factor, it also sets the \hsize and \vsize to true
>> dimensions with letter default, see plain.tex. So in the general
>> non-letter case one should say \mag=\magstep1 instead of using
>> \magnification.
>>> It seems that in TL2004 the file pdftex.cfg has vanished and is
>>> replaced by
>>> /usr/local/teTeX/share/texmf.local/tex/generic/config/ 
>>> pdftexconfig.tex,
>>> which contains all the proper settings:
>>> 	\pdfpagewidth=594.99 true bp
>>> 	\pdfpageheight=841.99 true bp
>>> 	\pdfhorigin=1 true in
>>> 	\pdfvorigin=1 true in
>>> - When this file is not read, the above result is obtained.
>>> - When this file is explicitly read (by \input pdftexconfig) after
>>> setting the magnification, namely:
>>> 	\magnification=\magstep1
>>> 	\input pdftexconfig
>>> then the paper size is brought back to A4 as it should.
>>> - When this file is read before setting the magnification, namely:
>>> 	\input pdftexconfig
>>> 	\magnification=\magstep1
>>> then an error is produced:
>>> 	(/usr/local/teTeX/share/texmf.local/tex/generic/config/
>>> pdftexconfig.tex)
>>> 	! Incompatible magnification (1200);
>>> 	 the previous value will be retained (1000).
>>> 	\m at g ->\mag \count@ \hsize 6.5true
>>> 	                                  in\vsize 8.9truein\dimen \footins
>>> 8truein
>>> 	<to be read again>
>>> 	                   \relax
>>> 	l.3 \magnification=\magstep1
>> The \hsize stuff in the error message is from the \m at g macro of
>> plain.tex. The error is caused by a TeX feature: After a \dimen  
>> has been
>> set to a "true" dimension in a certain \mag environment, the \mag is
>> frozen and can't be changed any more. Now, when the file
>> pdftexconfig.tex is read, some \dimen are set to true dimensions,  
>> like
>> \pdfpagewidth, so \mag=1000 is frozen. Then comes a new \mag  
>> (1200), and
>> then \hsize6.5truein from the \magnification helper macro \m at g  
>> triggers
>> the error message. Other examples:
>> \vsize=297truemm \mag=\magstep1 \hsize=210truemm \bye
>> gives a similar error message in TeX. It's nothing special with  
>> pdftex.
>> And
>> \vsize=297truemm \mag=\magstep1 \hsize=210mm \bye
>> is ok, as is this:
>> \vsize=297mm \mag=\magstep1 \hsize=210truemm \bye
>> A try on a few hints to avoid this true dimensions weirdness:
>> * Set \mag early.
>> * If you set anything to true dimensions _before_ setting \mag, you
>> can't do _after_ setting \mag. Vice versa.
>> * Set all necessary \dimen to true dimensions after \mag, even  
>> when they
>> already have had non-true values before \mag -- just to be sure, that
>> everything comes out right. For pdftex don't forget to set
>> \pdfpagewidth/height, \pdfhorigin, and \pdfvorigin to the wished true
>> dimensions.
>> * Or, prescale the \dimen to a non-true dimension so that it comes  
>> out
>> right after the \mag has been set to a new value.
>>> Is there something obvious I've done wrong? Or is this a bug in  
>>> pdfTeX?
>> It should be inline with how TeX's \mag is supposed to work.
>>> I've verified the same occurs with
>>> /usr/local/teTeX/share/texmf.tetex/tex/plain/base/story.tex, thus it
>>> doesn't seem specific to my TeX input file.
>>> Bruno Voisin
>> Regards, Hartmut

> De : Hartmut Henkel
> Date : 22 décembre 2004 01:10:41 HNEC
> À : Bruno Voisin
> Cc : TeX on Mac OS X Mailing List
> Objet : Rép : [tex-live] [Fwd: [OS X TeX] Bug in latest pdfTeX (and/ 
> or teTeX) with respect to \magnification?]
> On Tue, 21 Dec 2004, Bruno Voisin wrote:
>> Le 21 déc. 04, à 01:23, Gerben Wierda a écrit :
>>> I played post office with this question from Bruno:
>> Thanks for this, and to Hartmut for the clarification that followed.
>> So if I understood correctly, here is what happens:
>> - With previous versions of pdfTeX, up to TL2003, there were two ways
>> to set parameters: via TeX primitives in the TeX input file, and via
>> parameters in the configuration file pdftex.cfg. From the
>> documentation of TL2003:
> All you observed is right. Yes there were two ways, one pdftex.cfg  
> file
> in a special non-TeX format, which was a rather heterogenous approach.
> So it was somehow decided to scrap this special file, and do  
> everything
> consistently in the TeX language.
>>> A typical pdftex.cfg file looks like this, setting up output for A4
>>> paper size and the standard TEX offset of 1 inch, and loading two
>>> map files for fonts:
>>> 	[...]
>>> 	page_width	210 true mm	% A4 paper width
>>> 	page_height	297 true mm	% A4 paper height
>>> 	horigin		1 true in		% horizontal origin offset
>>> 	vorigin		1 true in		% vertical origin offset
>>> 	[...]
>>> The configuration file sets default values for these parameters, and
>>> apart from the map entry, they all can be over--ridden in the TEX
>>> source file. Dimensions can be specified as true, which makes them
>>> immune for magnification (when set).
>> The corresponding TeX primitives were:
>>> Most parameters in the configuration file have a corresponding
>>> internal register. When not set during the TEX run, pdfTEX uses the
>>> values as specified in the configuration file.
>>> internal name	parameters	type
>>> [...]
>>> \pdfhorigin		horigin		dimension
>>> \pdfvorigin		vorigin		dimension
>>> \pdfpageheight	page_height	dimension
>>> \pdfpagewidth 	page_width	dimension
>>> [...]
>> - With TL2004 the parameters have been suppressed, as well as the  
>> file
>> pdftex.cfg which is ignored, and all is set via the TeX primitives
>> which are initialized in the file pdftexconfig.tex read during the
>> creation of format files:
>>> % Set pdfTeX parameters for pdf mode (replacing pdftex.cfg file).
>>> % Thomas Esser, 2004. public domain.
>>> [...]
>>> \pdfpagewidth=594.99 true bp
>>> \pdfpageheight=841.99 true bp
>>> \pdfhorigin=1 true in
>>> \pdfvorigin=1 true in
>>> [...]
> These \dimen parameters aren't really initialized to true dimensions,
> the "true" has no effect here, as this stuff would be true dimensions
> only during initex, and the "true" would scale the dimension in initex
> only if it came _after_ a \mag != 1000. So one could leave the "true"
> out in pdftexconfig.tex, it's only sugar there. The \pdfpagewidth etc.
> values are then dumped into the format, and they are now treated like
> any other dimension, e. g. \hsize. So this way to do it should be more
> consistent. Yes and there is this slight backward incompatibility  
> (i had
> to change a few posters by adding true \pdfpagewidth etc. after the
> \mag; this were easy fixes).
>> - Now comes the question of \magnification. With TL2003, putting in a
>> plain TeX input file, processed by pdfTeX, the line
>> 	\magnification=\magstep1
>> magnified the text by 1.2 and reinitialized the size of the output  
>> box
>> (= the width and height of text) to their plain TeX default (= US
>> Letter paper). The parameters page_width, page_height, horigin and
>> vorigin, which had been set in pdftex.cfg in true units,...
> see the inconsistency: setting things to true _before_ \mag is  
> given has
> no effect. If it had, it was no TeX language here.
>> ...were not affected by the magnification and remained unchanged  
>> (= A4
>> paper for me).
>> - With TL2004, the line
>> 	\magnification=\magstep1
>> has the same effect on the size of text and output box as with  
>> TL2003.
>> It should also not affect the TeX primitives \pdfpagewidth,
>> \pdfpageheight, \pdfhorigin, \pdfvorigin, set in true units in the
>> file pdftexconfig.tex,
> as said above, these are _not_ set to true units. True things have  
> only
> effect if they come _after_ a \mag.
>> but apparently it does: the page dimensions are also multiplied by
>> \magstep1 (= 1.2).
>> I verified in pdftex.log that the file pdftexconfig.tex has indeed
>> been read when creating pdftex.fmt. So what can be happening? Is this
>> normal, or a bug?
> Well, i believe this will be the normal way, and causing a little
> trouble to legacy documents where \mag != 1000.
>> This behaviour might be a problem with respect to backwards
>> compatibility and compatibility with other TeX engines: take  
>> story.tex
>> and add at its beginning the single line
>> 	\magnification=\magstep1
>> That is a perfectly legitimate plain TeX file, not using any
>> dvips-specific or eTeX-specific or anything-specific extension, and
>> yielding a given output with TeX + dvips + GhostScript. Then process
>> the same file with pdfTeX, you'll get a different output. At least
>> that's what it does on my setup.
> Since pdftex combines a TeX engine plus a pdf backend, these media
> related parameters have to be fed somehow to pdftex. So the case is
> different from a split TeX + dvips approach, and it's something to be
> decided whether there should be a few special dimensions like
> \pdfpagewidth and friends that would not be handled like other
> dimensions after a \mag. Now this special case has been removed.
> And you could as well tell dvips that it should scale the media  
> size by
> the -T option.
>> Or am I making a lot of fuss for nothing, and is the page size, as
>> displayed by Acrobat Reader, for example, irrelevant, given that when
>> you send the file to a printer only the size of the text and the
>> position of the origin will be taken into account, so that the  
>> printed
>> output will be the same for dvips and pdfTeX? (Assuming that you
>> disabled Acrobat's automatic rescaling to fit the page size specified
>> in the GUI printer driver.)
> It's relevant, one needs to have a MediaBox fitting to the document  
> also
> for scaled output.
>> I had not noticed before the fact that \magnification reinitialized
>> the page size to US Letter, since I had always followed it by
>> specification of \hsize, \vsize, \hoffset and \voffset to fit with A4
>> paper. At least now I understand why, in the letter example at the
>> beginning of Appendix E of the TeXbook, Knuth says
>> 	\magnification=\magstep1
>> 	\input letterformat
>> (letterformat.tex setting \hsize, \vsize and \voffset), and not
>> 	\input letterformat
>> 	\magnification=\magstep1
>> Thus the moral of the story seems to be: after setting \mag or
>> \magnification, always redefine TeX page size parameters (\hsize,
>> \vsize, \hoffset and \voffset) and pdfTeX page size parameters
>> (\pdfpagewidth, \pdfpageheight, \pdfhorigin and \pdfvorigin), in true
>> units.
> Yes. Or maybe pre-scale before the \mag.
>> It's a pity these two sets of parameters are not made transparently
>> dependent on each other, as they are in LaTeX, so that you don't have
>> to set one and the other.
> They are completely independent, as usual, e. g. like \hoffset is from
> \hsize. If you increase \hoffset, \hsize is not automatically  
> shrinking.
> This is automatically done by the geometry package, which in principle
> also could handle all these media related calculations, but AFAIK when
> \mag != 1000, even the geometry package with older pdftex had problems
> to do the right thing. The \pdfpagewidth... handling now seems to be
> more logical. Don't you agree?
> Regards, Hartmut
------------------------- Info --------------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
          & FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Archive: http://tug.org/pipermail/macostex-archives/

More information about the MacOSX-TeX mailing list