[OS X TeX] dvips problem
Peter Dyballa
Peter_Dyballa at Web.DE
Sun Nov 7 15:06:32 CET 2010
Am 07.11.2010 um 07:05 schrieb <lycee.condorcet at voila.fr> <lycee.condorcet at voila.fr
>:
> 000117: PSfile="efforts-rubadh.eps.gz" llx=0 lly=0 urx=842 ury=595
> rwi=2834
This line tells that a page sized EPS image (landscape, 842×595
PostScript or TeX big points) is included – which may not be true...
In the absence of a BB file LaTeX writes into my DVI output file:
000117: PSfile="1a.eps.gz" llx=0 lly=0 urx=72 ury=72 rwi=2834
1"×1", although it has a different size. This is recorded in the DVI
output file when the BB file is present:
000117: PSfile="1a.eps.gz" llx=20 lly=20 urx=555 ury=329 rwi=2834
Look into your LOG file! When you claim "No there is no problem with
dvips" then the problem has to be with latex, the creator of the DVI
file, on which, may it be faulty or correct, dvips has to work. When
dvips works correctly, then a faulty DVI file is converted to a faulty
PS file.
Xdvi is no good witness: It inserts the picture (and for me one falls
off the right edge). The same is presumingly true for dvipdf (or
dvipdfm or dvipdfmx): Either the pictures are included at their real
size and fall off some edge or the more clever dvipdfm and dvipdfmx
can read the
%%BoundingBox: 20 20 555 329
comment in the EPS file and work on them more sanely. Given the *PS
files are not compressed or a rule is given which describes how to
handle them.
A BB file (1a.eps.bb) can have this contents (the HiResBoundingBox is
not always useful):
%Title: ./1a.eps
%%Creator: ebb Version 0.5.2
%%BoundingBox: 20 20 555 329
%%HiResBoundingBox: 20.000000 20.500000 555.000000 328.500000
%%CreationDate: Tue Jul 1 00:48:52 2008
--
Greetings
Pete
What is this talk of 'release?' Klingons do not make software
'releases.' Our software 'escapes,' leaving a bloody trail of
designers and quality assurance people in its wake.
More information about the macostex-archives
mailing list