[XeTeX] wrong paper size (geometry and truedimen)
bvoisin at mac.com
Tue Jun 27 17:31:57 CEST 2006
Le 26 juin 06 à 14:02, Will Robertson a écrit :
> See the thread on c.t.t. earlier this year:
> (that's the solution, the whole thread is a little convoluted.)
Related to the meaning of true units and the effect of \mag and
\magnification in pdfTeX, there has been a thread long time ago on
the OS X TeX list, to which Hartmut Henkel, one of the developers of
pdfTeX IIRC, contributed. I think that the answer was, essentially,
that even if \pdfpageheight and \pdfpagewidth are specified in true
units in the pdfTeX initialization file /usr/local/teTeX/share/
texmf.gwtex/tex/generic/config/pdftexconfig.tex, the "true" here
means nothing and the parameters are affected by any subsequent \mag.
Even stranger, it seemed that according to the developers of pdfTeX
this is intended behaviour.
I'm not able to follow the present discussion closely (away in Sweden
for the week, and for a few minutes only on a wireless network), but
off my OS X TeX mailbox here is one of the posts in the past thread.
> 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
> in a special non-TeX format, which was a rather heterogenous approach.
> So it was somehow decided to scrap this special file, and do
> 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
>> 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
>> magnified the text by 1.2 and reinitialized the size of the output
>> (= 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
>> has the same effect on the size of text and output box as with
>> 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
> 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
>> and add at its beginning the single line
>> 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
>> 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
> 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
>> \input letterformat
>> (letterformat.tex setting \hsize, \vsize and \voffset), and not
>> \input letterformat
>> 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
> 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
> 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
More information about the XeTeX