On Tue, Oct 31, 2006 at 09:31:26PM +0100, Georg Baum wrote: > I see the same behaviour, but I don't agree with the solution. The problem > here is that the image is detected by LyX as PS, not EPS, because the > first line reads > > %!PS-Adobe-2.0 > > and not > > %!PS-Adobe-2.0 EPSF-2.0 > > Therefore ps2pdf is used to convert it to pdf, not epstopdf. If you fix the > first line of the image and set the rotation to 270 degrees you get the > same orientation in LyX, in DVI and pdf output. > > The right fix for this problem is IMO not to introduce a separate rotation > option for display, but to convert ps files to eps with ps2eps for > included figures. This conversion will be a noop (except from the changed > first line) in your case, but if an included file is really PS and not EPS > with a wrong declaration then it will generate a LaTeX failure. > This is the only case I know where the indirect route PS -> EPS -> PDF > gives a better result than the direct route PS -> PDF. > Another possible solution would be to define another pdf format "pdf4" that > is only used for included graphics, and to define both the eps -> pdf4 and > ps -> pdf4 converter as epstopdf. > > This is exactly what I wrote previously: These cases of wrong rotation are > always caused by a faulty converter, and therefore the converter should be > fixed and no extra rotation option for display introduced.
Yes, you convinced me. Probably I forgot to add the eps specification to the gnuplot command setting the postscript terminal. I noticed that the boundingbox was there but didn't pay attention to the first line... However, this file is indeed an eps one, as if I add EPSF-2.0 to the first line, I get: $ epstool --test-eps image.ps ... File claims to be EPS. PASS: File appears to be well behaved EPS. OK I am wondering if it is worth trying such a check when deciding whether ps2pdf or epstopdf is to be used, instead of defining a further pdf4 format. -- Enrico
