pstricks-add question (bug?): bounding box changes with usepackage
Ted Pavlic
%===== miniaddtest.tex =====
\documentclass{article}
\usepackage{pstricks, pst-plot}
%\usepackage{pstricks-add}
\usepackage{pst-eps}
\begin{document}%
\begin{TeXtoEPS}%
\begin{pspicture}(0,0)(5,5)%
\psaxes[axesstyle=frame,labels=none,ticks=none]%
(0,0)(5,5)%
\rput(2.5,2.5){Some text}%
\end{pspicture}%
\end{TeXtoEPS}%
\end{document}
%=====
I build this example (using TeXLive 2007 on OS X) with:
latex miniaddtest.tex
dvips -E miniaddtest.dvi -o miniaddtest.eps
epstopdf miniaddtest.eps
What is produced is a box with "Some text" in the middle of it. That
box is EXACTLY 5 centimeters by 5 centimeters. The bounding box of the
graphic follows the frame drawn with the psaxes command.
Notice that pstricks-add is commented out in the code. If you
UNCOMMENT that line, the bounding box changes so that there's space on
the left and bottom of the figure.
It appears like it's the \rput line that messes things up. If I
comment out the \rput, then everything works with pstricks-add.
I've had similar bounding box problems with pstricks-add. I like to
build my figures this way because it makes journal editors happier
when they get rendered EPS files.
What's going on? I'm using PSTricks version 2.82. Filedate on pstricks-
add.tex is 2006/11/22. I think pstricks-add redefines rput. Is that
the problem?
Thanks --
Ted
Christoph Bersch
Ted Pavlic schrieb:
>
> I build this example (using TeXLive 2007 on OS X) with:
>
> latex miniaddtest.tex
> dvips -E miniaddtest.dvi -o miniaddtest.eps
> epstopdf miniaddtest.eps
>
> I've had similar bounding box problems with pstricks-add. I like to
> build my figures this way because it makes journal editors happier
> when they get rendered EPS files.
I don't know why this happens but I also generate separate eps files
with PSTricks for my documents. Before calling 'epstopdf' I invoke
'epstool' which can nicely adjust the bounding box. So I do not have to
adjust the pspicture size meticulously:
latex file.tex
dvips -E file.tex -o tmp.eps
epstool --bbox --copy --ouput file.eps tmp.eps
epstopdf file.eps
Hope this helps you,
Christoph
Herbert Voss
> What's going on? I'm using PSTricks version 2.82. Filedate on pstricks-
> add.tex is 2006/11/22. I think pstricks-add redefines rput. Is that
> the problem?
the problem is dvips, it calculates a wrong bounding box.
You can test it with
gs -sDEVICE=bbox file.eps
it should show in both cases the same bounding box values.
Herbert
Ted Pavlic
> Ted Pavlic schrieb:
>
> > What's going on? I'm using PSTricks version 2.82. Filedate on pstricks-
> > add.tex is 2006/11/22. I think pstricks-add redefines rput. Is that
> > the problem?
>
> the problem is dvips, it calculates a wrong bounding box.
But isn't it strange that everything works *fine* as long as I'm not
using pstricks-add and any version of rput? If I use an rput without
pstricks-add, I get the correct bounding box.
The epstool trick mentioned above seems to work fine for me.
I'm using dvips bcause that's what pst-eps tells me to use. Is there a
better alternative that will do the conversion without wrecking the
bounding box? (note: the preview package seems to ignore PSTricks
bounding boxes entirely)
Thanks --
Ted
Herbert Voss
> On Sep 8, 8:17 am, Herbert Voss <herber...@googlemail.com> wrote:
>> Ted Pavlic schrieb:
>>
>>> What's going on? I'm using PSTricks version 2.82. Filedate on pstricks-
>>> add.tex is 2006/11/22. I think pstricks-add redefines rput. Is that
>>> the problem?
>> the problem is dvips, it calculates a wrong bounding box.
>
> But isn't it strange that everything works *fine* as long as I'm not
> using pstricks-add and any version of rput? If I use an rput without
> pstricks-add, I get the correct bounding box.
no, that is a known issue that dvips -E works in a random way ...
>
> The epstool trick mentioned above seems to work fine for me.
>
> I'm using dvips bcause that's what pst-eps tells me to use. Is there a
> better alternative that will do the conversion without wrecking the
> bounding box? (note: the preview package seems to ignore PSTricks
> bounding boxes entirely)
with pst-pdf _everything_ works fine when you have a correct
pspicture environment or everything in a psotscript environment.
Herbert
Heiko Oberdiek
> On Sep 8, 8:17 am, Herbert Voss <herber...@googlemail.com> wrote:
> > Ted Pavlic schrieb:
> >
> > > What's going on? I'm using PSTricks version 2.82. Filedate on pstricks-
> > > add.tex is 2006/11/22. I think pstricks-add redefines rput. Is that
> > > the problem?
> >
> > the problem is dvips, it calculates a wrong bounding box.
>
> But isn't it strange that everything works *fine* as long as I'm not
> using pstricks-add and any version of rput? If I use an rput without
> pstricks-add, I get the correct bounding box.
Pure luck. Option -E is nothing more than a guess.
Keep in mind, dvips doesn't know what happens with specials, for
example. A special can be invisible or it can put something on the
page with unknown location. Dvips does not embed a PostScript
interpreter.
For more reliable results, use GhostScript's bbox device (see
epstool).
> The epstool trick mentioned above seems to work fine for me.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Ted Pavlic
> > using pstricks-add and any version of rput? If I use an rput without
> > pstricks-add, I get the correct bounding box.
>
> no, that is a known issue that dvips -E works in a random way ...
OK.
> > The epstool trick mentioned above seems to work fine for me.
One bad thing about using the GhostScript bbox driver to generate the
bounding box is that my pspicture environment's bounding box is
ignored. That is, if I **WANT** a large region of whitespace on the
edges of my figure, I need to put some sort of dummy graphic out
there. Like a...
\psdot[linecolor=white](-50,0)
Is there a better fix than using a hidden dot to get the gs bbox
driver to keep from being OVERLY tight?
> with pst-pdf _everything_ works fine when you have a correct
> pspicture environment or everything in a psotscript environment.
OK. I'll have to give pst-pdf a try.
What about psmatrix environments? Will pst-pdf properly bound those?
Thanks for your help --
Ted
Herbert Voss
> \psdot[linecolor=white](-50,0)
>
> Is there a better fix than using a hidden dot to get the gs bbox
> driver to keep from being OVERLY tight?
\psframebox[framesep=20pt,linecolor=white]{ ... }
>> with pst-pdf _everything_ works fine when you have a correct
>> pspicture environment or everything in a psotscript environment.
>
> OK. I'll have to give pst-pdf a try.
>
> What about psmatrix environments? Will pst-pdf properly bound those?
yes
Herbert
Marc van Dongen
> Hi,
>
> Ted Pavlic schrieb:
>
>
>
> > I build this example (using TeXLive 2007 on OS X) with:
>
> > latex miniaddtest.tex
> > dvips -E miniaddtest.dvi -o miniaddtest.eps
> > epstopdf miniaddtest.eps
>
> > I've had similar bounding box problems with pstricks-add. I like to
> > build my figures this way because it makes journal editors happier
> > when they get rendered EPS files.
>
> I don't know why this happens but I also generate separate eps files
> with PSTricks for my documents. Before calling 'epstopdf' I invoke
> 'epstool' which can nicely adjust the bounding box. So I do not have to
> adjust the pspicture size meticulously:
As it turns out certain graphicx options and/or using the graphicx
package may also affect the page size.
I've been using the llncs style to produce a collection of papers in a
proceedings, and I've always been wondering why some of the papers
had different page sizes. I had never been able to find the reason
until yesterday after this thread pointed me in the right direction.
I've now managed to get rid of the problem, but the solution is not
great: I had to include a \usepackage{graphics} for some of the
individual articles even if they didn't use graphics.sty. Also I had
to remove some options for the graphicx package in some other
articles. Needless to say, this is not a great solution.
Regards,
Marc van Dongen
Heiko Oberdiek
> I've been using the llncs style to produce a collection of papers in a
> proceedings, and I've always been wondering why some of the papers
> had different page sizes. I had never been able to find the reason
> until yesterday after this thread pointed me in the right direction.
> I've now managed to get rid of the problem, but the solution is not
> great: I had to include a \usepackage{graphics} for some of the
> individual articles even if they didn't use graphics.sty.
LaTeX alone does not emit the driver dependent specials to
set the paper size. Usually it's done by package geometry or
typearea. For pdfTeX, it is also be done by pdftex.def or hyperref's
hpdftex.def.
Which driver you are using?
> Also I had
> to remove some options for the graphicx package in some other
> articles. Needless to say, this is not a great solution.
Which options?
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Marc van Dongen
> Marc van Dongen <don...@cs.ucc.ie> wrote:
[ Problems when producing llncs proceedings and different page
sizes. ]
> LaTeX alone does not emit the driver dependent specials to
> set the paper size. Usually it's done by package geometry or
> typearea. For pdfTeX, it is also be done by pdftex.def or hyperref's
> hpdftex.def.
>
> Which driver you are using?
I'm translating straight from LaTeX to pdf using pdflatex. All
included graphics were pdf. There were no hyperlink-related package
includes (at least at the top level...).
> > Also I had
> > to remove some options for the graphicx package in some other
> > articles. Needless to say, this is not a great solution.
> Which options?
o Using dvipdfm with graphicx seemed to make the page size larger than
using graphicx without using it.
o Using graphicx without any options seemed to make the page size
smaller than without using graphicx at all.
Regards,
Marc van Dongen
Heiko Oberdiek
> On Sep 9, 10:53 am, Heiko Oberdiek <oberd...@uni-freiburg.de> wrote:
> > Marc van Dongen <don...@cs.ucc.ie> wrote:
>
> [ Problems when producing llncs proceedings and different page
> sizes. ]
>
> > LaTeX alone does not emit the driver dependent specials to
> > set the paper size. Usually it's done by package geometry or
> > typearea. For pdfTeX, it is also be done by pdftex.def or hyperref's
> > hpdftex.def.
> >
> > Which driver you are using?
>
> I'm translating straight from LaTeX to pdf using pdflatex. All
> included graphics were pdf. There were no hyperlink-related package
> includes (at least at the top level...).
As I said, pdftex.def sets the PDF page box (MediaBox).
But you can also use package geometry instead of
graphic{s|x}|color|hyperref.
> > > Also I had
> > > to remove some options for the graphicx package in some other
> > > articles. Needless to say, this is not a great solution.
>
> > Which options?
>
> o Using dvipdfm with graphicx seemed to make the page size larger than
> using graphicx without using it.
"seemed"? I couldn't found a page size setting feature in dvipdfm.def.
There are many programs that can tell you the page size:
* pdfinfo
* AcrobatReader, depending on version, e.g. going to the left lower
corner.
* Look at the PDF directly with a pager, editor, hex editor, ... and
look for "MediaBox", the bounding box consisting of four numbers
follow, unit is bp.
> o Using graphicx without any options seemed to make the page size
> smaller than without using graphicx at all.
* The correct page size must be set, default of standard classes
is letter.
* Driver part (explained previously)
Example (pdftex):
\documentclass[a4paper]{article}
\usepackage{geometry}
For dvi drivers you may need the correct driver option.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Marc van Dongen
[seemingly different page sizes with/without graphicx]
> "seemed"? I couldn't found a page size setting feature in dvipdfm.def.
> There are many programs that can tell you the page size:
As I wrote before, I compiled the individual papers using the llncs
style. I then collected them into a single document using pdftk (this
was not in my original posting).
The page sizes of the resulting document were *definitely* different
if I omitted dvipdfm. They were *definitely* different if I included
graphicx.
> * pdfinfo
> * AcrobatReader, depending on version, e.g. going to the left lower
> corner.
> * Look at the PDF directly with a pager, editor, hex editor, ... and
> look for "MediaBox", the bounding box consisting of four numbers
> follow, unit is bp.
I wrote *seemed* because I didn't measure. However, by looking at the
page sizes of the resulting document which was compiled using pdftk
the page sizes were different (I could tell because I could see one
page of each document side-by-side).
> Example (pdftex):
> \documentclass[a4paper]{article}
> \usepackage{geometry}
The geometry package was not used (at the top level articles). All
articles were compiled using \documentclass[runningheads]{llncs}. To
the best of my knowledge the llncs class does not have any options
which affect the page size (I also checked the class file and could
find none).
For example, if I'm using the following two documents:
\documentclass[runningheads]{llncs}
\title{A}
\author{A}
\begin{document}
\thispagestyle{empty}
\mainmatter
\maketitle
\end{document}
\documentclass[runningheads]{llncs}
\usepackage{graphicx}
\title{B}
\author{B}
\begin{document}
\thispagestyle{empty}
\mainmatter
\maketitle
\end{document}
Now pdfinfo tells me the two have different page sizes:
o First: Page size: 595.276 x 841.89 pts (A4)
o Second: Page size: 612 x 792 pts (letter)
Regards,
Marc van Dongen
Heiko Oberdiek
> For example, if I'm using the following two documents:
>
> \documentclass[runningheads]{llncs}
> \title{A}
> \author{A}
> \begin{document}
> \thispagestyle{empty}
> \mainmatter
> \maketitle
> \end{document}
>
> \documentclass[runningheads]{llncs}
> \usepackage{graphicx}
> \title{B}
> \author{B}
> \begin{document}
> \thispagestyle{empty}
> \mainmatter
> \maketitle
> \end{document}
>
> Now pdfinfo tells me the two have different page sizes:
> o First: Page size: 595.276 x 841.89 pts (A4)
> o Second: Page size: 612 x 792 pts (letter)
First document:
llncs load the article class. Nobody has set the paper size
explicitly, thus the default is letter. You can query the LaTeX
lengths \paperwidth and \paperheight. However pdfTeX doesn't
know about user (user = LaTeX kernel) defined length registers,
it uses special dimen registers for the page size: \pdfpagewidth
and \pdfpageheight. As already said, the LaTeX kernel ignores
driver specific stuff, thus \pdfpagewidth and \pdfpageheight have
the values assigned to them during format generation. Your default
is apparently A4.
--> The PDF page size is wrong.
Second document:
Here the graphicx package loads driver pdftex.def that reads
LaTeX's page size \paperwidth and \paperheight and sets
pdfTeX's page size \pdfpagewidth and \pdfpageheight, thus
you got the correct result.
--> Result: correct
If you dislike the idea of having to load a graphic{s,x}/color
package without using graphics or color, then geometry is
an alternative. It's main purpose is dealing with page layout.
If you have expected A4 as correct page size, then you
had misinformed LaTeX. You need option `a4paper' then.
The class llncs passes the option to article class that
sets \paperwidth and \paperheight.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Marc van Dongen
> Marc van Dongen <don...@cs.ucc.ie> wrote:
>
>
>
> > For example, if I'm using the following two documents:
[document settings]
> If you dislike the idea of having to load a graphic{s,x}/color
> package without using graphics or color, then geometry is
> an alternative. It's main purpose is dealing with page layout.
>
> If you have expected A4 as correct page size, then you
> had misinformed LaTeX. You need option `a4paper' then.
> The class llncs passes the option to article class that
> sets \paperwidth and \paperheight.
Thanks for that. I don't agree that anybody misinformed LaTeX. Nobody
hadinformed LaTeX about changes in the page setting. Therefore they
should expect the default. For some reason some package writer decided
to change the default.
Now I *do* think that it is quite fine to expect that including
packages like a4wide, a4, or geometry should affect the page size.
However, in the example programs which I posted, the only difference
was the inclusion of the graphicx package. In my opinion including a
package like graphicx (or babel) shouldn't have such unexpected side-
effects as changes in the page size.
Regards,
Marc van Dongen
Heiko Oberdiek
> On Sep 9, 3:24 pm, Heiko Oberdiek <oberd...@uni-freiburg.de> wrote:
> > Marc van Dongen <don...@cs.ucc.ie> wrote:
> >
> >
> >
> > > For example, if I'm using the following two documents:
>
> [document settings]
>
> > If you dislike the idea of having to load a graphic{s,x}/color
> > package without using graphics or color, then geometry is
> > an alternative. It's main purpose is dealing with page layout.
> >
> > If you have expected A4 as correct page size, then you
> > had misinformed LaTeX. You need option `a4paper' then.
> > The class llncs passes the option to article class that
> > sets \paperwidth and \paperheight.
>
> Thanks for that. I don't agree that anybody misinformed LaTeX. Nobody
> hadinformed LaTeX about changes in the page setting. Therefore they
> should expect the default.
The default is *LETTER* with class article (llncs), not A4, read the
documentation. Therefore the result A4 is the wrong result.
You need an additional package to propagate the
paper setting to PDF.
If you have forgotten to tell the class about A4, then it's clearly
your error. Also the class calculates the page layout based on
this information. Thus you got a layout for letter, not A4.
> For some reason some package writer decided
> to change the default.
No, the correct behaviour is implemented.
> Now I *do* think that it is quite fine to expect that including
> packages like a4wide, a4, or geometry should affect the page size.
> However, in the example programs which I posted, the only difference
> was the inclusion of the graphicx package. In my opinion including a
> package like graphicx (or babel) shouldn't have such unexpected side-
> effects as changes in the page size.
There is *no* side effect in this sence. The driver file only reads
\paperwidth, \paperheight, it doesn't change them.
Additionally it sets \pdfpagewidth, \pdfpageheight.
Yours sincerely
Heiko <ober...@uni-freiburg.de>