Fwd: [tex-live] [Fwd: [OS X TeX] Bug in latest pdfTeX (and/or teTeX) with respect to \magnification?]

Tue Dec 21 19:26:19 EST 2004

> De: Hartmut Henkel
> Date: 22 décembre 2004 01:10:41 GMT+01:00
> À: 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 Post: <mailto:MacOSX-TeX at email.esm.psu.edu>