I think I discovered a bug in the graphicx package of LaTeX2e.
when I include a ps file using the graphics package I get an error message in
one case:
\includegraphics[angle=270, height=30mm]{overview.ps}
gives me:
! Package graphics Error: Division by 0.
See the graphics package documentation for explanation.
Type H <return> for immediate help.
...
l.181 ...phics [angle=270, height=30mm]{overview.ps}
Overfull \hbox (403.04594pt too wide) in paragraph at lines 181--182
[][]
And then the ps file is included in its original size.
Every other combination of the keys, i. e.
[angle=270, width=30mm]
[width=30mm, angle=270]
[height=30mm, angle=270]
does what it should.
This applies for all angles between 180 and 270 degrees.
Angles between 0 and 90 degrees are treated correctly,
for angles between 90 and 180 and between 270 and 360 the scaling is wrong.
It seems like there is a division somewhere instead of a multiplication.
Any explanation?
Thanks,
Heiko
PS: I use LaTeX2e <1996/6/1> on a Linux (Debian 1.2) PC
-----------------------------------------------------------------------------
Heiko Selber (Fritz-Haber-Institut Berlin) | Vs lbh pna ernq guvf |
http://www.fhi-berlin.mpg.de/~selber | lbh unir jnfgrq lbhe gvzr. |
email: sel...@fhi-berlin.mpg.de | (un un un) |
Phone:+49-30-8413-4574, Fax:+49-30-8413-4686 |____________________________|
This is a feature, not a bug. In latex there is a big
difference between "height" and "totalheight". You
probably want "totalheight" instead.
This is documented in the graphics package documentation,
and the graphics bundle documentation (grfguide). It is
also is covered in
ftp://ftp.tex.ac.uk/tex-archive/info/epslatex.ps
Good luck,
Keith
The graphics packages are supported software; you should check the
bugs database... AIUI this isn't a bug, it's a feature... :-)
The wonderful URL
(which the basic thing
http://www.cogs.susx.ac.uk/cgi-bin/ltxbugs2html?introduction=yes
generated automagically for me) says:
[...] however in fact the solution can be found in two other reports:
graphics/1339: Combination of \resizebox and \rotatebox failing
graphics/1531: overflow in graphicx computations
graphics/1665: \includegraphics[angle=-90,height=3.5in]{.} is broke
Also in the updated version of grfguide.tex that went out in September
which says
\item[totalheight]\NEWfeature{1995/06/01}
[I presume graphics/1665 was included in error, since that's the one
David said didn't contain the solution, as a result of an error of
some sort...]
--
Robin (Campaign for Real Radio 3) Fairbairns r...@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge CB2 3QG, UK
Home page: http://www.cl.cam.ac.uk/users/rf/robin.html
> I think I discovered a bug in the graphicx package of LaTeX2e.
Please see the documentation of the totalheight key
David
Ah, my version of grfguide.tex is too old. I'll talk to the debian package
maintainer.
It's a pity that the height of an object is not its height (a bit
counterintuitive, isn't it?).
Thanks,
Heiko
-----------------------------------------------------------------------------
Heiko Selber (Fritz-Haber-Institut Berlin) | I condem'n the abuse |
http://www.fhi-berlin.mpg.de/~selber | of apostrophe's. |
email: sel...@fhi-berlin.mpg.de | |
I think they're looking for a new one (I was approached when I first
asked the Debian guys around here about my first ever Debian install
recently -- I thought I ought at least to get used to the system first
;-).
>It's a pity that the height of an object is not its height (a bit
>counterintuitive, isn't it?).
The height is the "height above the baseline". If you rotate the
object so that it's entirely below the baseline, what would you expect
it to be?
I would claim that the name "totalheight" _is_ confusing: what it's
actually talking about is "sum_of_height_and_depth". OTOH, I would
rather be expected to type "totalheight"...
> It's a pity that the height of an object is not its height (a bit
> counterintuitive, isn't it?).
(La)TeX consistently measures `height' from the baseline so `a' and
`g' have the same height (in most fonts) despite the fact that g has a
descender.
David
"> "(La)TeX consistently measures `height' from the baseline so
> This is not perfectly true.
> In cases of minipages, it matters whether they end in
> a descenderless line or not.
It is true if you read it the right way (I think:-) What I meant to
imply was that LaTeX `height' (ie TeX \ht) relates to the height of
the box above the base line.
It is true that the `height' of a minipage is affected in assorted
unpleasent ways if you end the box with \hrule or a vertical space or
whatever, however the position of the baseline is also affected in the
same way, so I claim my statement is still true.
David
This is not perfectly true. In cases of minipages, it matters whether they end in
a descenderless line or not. This can be easily demonstrated by usinge a
\hrule after the minipage.
I have applied a special command \unterlaenge in some work of mine, to
correct such situations.
--J"org Knappen.
"> "
"> "David
"> "