[OS X TeX] TeXShop previews in LANDSCAPE mode
Bruno Voisin
bvoisin at mac.com
Sat Jul 15 17:43:11 CEST 2006
Le 14 juil. 06 à 22:08, Morten Høgholm a écrit :
> On Fri, 14 Jul 2006 21:55:43 +0200, Maarten Sneep
> <maarten.sneep at xs4all.nl> wrote:
>
>> I seem to recall that there were some issues with true measures,
>> magsteps and pdftex. It seems that
>>
>> - the magn is frozen as soon as the first code is written to the
>> pdf file
>> - the magn is applied to everything
>>
>> (found those statements by Hans Hagen after some Googling). You
>> certainly need to set the \pdfpage{width|height} parameters, but
>> the true may or may not have the intended effect. These messages
>> were specifically about 1.20, the issue may have been resolved by
>> now.
>
> Take a look at the thread starting at <http://www.ntg.nl/pipermail/
> ntg-pdftex/2006-February/002001.html>.
Interesting. So the attitude of the pdfTeX team hasn't changed with
respect to \magnification and true units since end-2004 (see below);
it appears still to go against intuition so blatantly. Glad to see
there are thick-skinned people pushing for common sense to prevail.
Bruno Voisin
> 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 macostex-archives
mailing list