[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



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