Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I am using the latest ubuntu with the texlive-full package. When I do a simple \includegraphics like this:

\begin{figure}[h]
  \centering
    \rotatebox{-90}{\includegraphics[width=8cm]{problem1}}
  \label{fig:prob1}
\end{figure}

if I don't include the \rotatebox command, my figures are rotated 90 deg. counterclockwise. Additionally, I get this warning:

** WARNING ** << /Rotate 90 >> found. (Not supported yet)

when rendering using XeLaTeX.

It seems like I have the same problem as this bloke: http://www.mail-archive.com/xetex@tug.org/msg01532.html

Is there a fix? This does not happen on my other (older) Ubuntu.

share|improve this question
    
What's important here is the version of XeTeX you have. Could you post the 'banner' line it prints at the start of a run? (Ubuntu tends to be behind the 'standard' TeX Live release schedule. TeX Live 2010 is current, but I think Ubuntu only has TeX Live 2009 with an older XeTeX version.) –  Joseph Wright Feb 2 '11 at 7:57
    
How are you generating your images, and in which format are they? –  Juan A. Navarro Feb 2 '11 at 7:58
    
Images are in eps, generating them in R. In the evince reader, they seem to have the correct orientation. –  stevejb Feb 2 '11 at 8:33
    
My xetex banner is This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009/Debian) –  stevejb Feb 2 '11 at 8:33
1  
@stevejb. Perhaps we might have a link to a demonstration graphics file? I have no problem rotating with XeLaTeX with examples at my disposal (and TeX Live 2010). –  Joseph Wright Feb 2 '11 at 16:33
show 8 more comments

5 Answers

up vote 5 down vote accepted

Well, i have no answer, but i believe i can give you some hints.

As i said in comment, i guess that your eps graphics files do have that "/Rotate 90" commands inside, and it's quite ok. You can check this using this command:

grep "Rotate 90" graphics.eps

(just replace "graphics.eps" with your image file name)

So, i think that the problem is with XeLaTeX's graphics driver. I can not check this, i have no such images around me.

Anyway, i would try to "re-eps" such images with eps2eps; it claims it "performs the equivalent optimization for Encapsulated PostScript (EPS) files".

Not sure that this can help, though.


Update

I've edited your EPS file (using vim), please see the difference:

 %%+ font Helvetica-Oblique
 %%+ font Helvetica-BoldOblique
 %%+ font Symbol
-%%DocumentMedia: letter 612 792 0 () ()
+%%DocumentMedia: letter 792 612 0 () ()
 %%Title: R Graphics Output
 %%Creator: R Software
 %%Pages: (atend)
@@ -12,7 +12,7 @@
 %%BoundingBox: 54 144 558 648
 %%EndComments
 %%BeginProlog
-/bp  { gs 612.00 0 translate 90 rotate gs } def
+/bp  { gs 0 0 translate 0 rotate gs } def
 % begin .ps.prolog
 /gs  { gsave } def
 /gr  { grestore } def

Here is the result -- achieved with LaTeX, not XeLaTeX (!!):

enter image description here

So, this is not a solution really, but rather a demonstration (i could find "better" numbers, possibly). So, i do believe that [xe]latex can not display you eps graphic files. Yes, i've tried with eps2eps with no success. Oh, well, i've replaced \usepackage{Sweave} with \usepackage{graphicx}, i hope it didn't any difference.

With XeLaTeX result is just the same with my texlive (2009-7, current Ubuntu's one, i believe).

Well, this is very attractive .)


Update 2

inkscape --export-eps=hist50-good.eps hist50.eps

This produces "good" EPS (4678 source expanded to file 78626 bytes long! but quite usable, i'd say).

inkscape --export-text-to-path --export-eps=hist50-good.eps hist50.eps

This reduses size to 40435 bytes.

As a result, correct page produced.

I think you can process all EPS files in a batch (be sure to make a backup,)

I am still not sure that this can be a solution for you.

ps. i feel like it's a bug?.. Your images are quite good, at least gv (3.6.8 here) and inkscape (0.47 r22583 here) shows them right.

share|improve this answer
    
I just checked for the string Rotate in all my eps files. Nothing. –  stevejb Feb 3 '11 at 23:27
    
Thanks for the tips. I suppose what I can do is just write a script which batch processes unprocessed eps files before xelatex gets called. I really appreciate the help. –  stevejb Feb 7 '11 at 22:40
    
so do you think this is a bug in xelatex for handling certain flags in the eps images? I bet the same would not happen for, say, pngs. I suppose the immediate solution is just to use some other format, although eps would be nice. –  stevejb Feb 7 '11 at 22:48
    
You can declare graphics rule to process on the fly: tex.stackexchange.com/questions/4979/…) –  brownian Feb 8 '11 at 10:17
    
@stevejb: no, not xelatex, because of having the same result with latex->dvips, pdflatex etc. Yes, that what i wrote means that i claim that there is a bug somewhere in "latex core" -- i don't know actually, i am not professional enough for that. But your images are correct (from both gv's and inkscape's perspective). –  brownian Feb 8 '11 at 10:20
add comment

I also don't really have an anwer, I just want to confirm that the problem still exists - and I would call it a problem, if pdflatex and xelatex do not produce the same results, ie. one rotates a figure and the other one does not .. It is definitely problem for me, because I share documents with others and some would compile it with pdflatex and others with xelatex..

I have encountered the problem first now, with a pdf produced by Adobe Acrobat - so I have no eps to fix. Interestingly, the same problem exists with TeXLive 2009 on linux and MikTeX 2.9 on Windows, so it really is xelatex issue..

As for solutions, one thing I did was to use gsview, convert the pdf to eps and then back to pdf - the resulting file is almost 3x bigger, but works with both engines.

An alternative would be using \ifxetex{\rotatebox{-90}{--}} for the affected figures - not elegant and possibly also not future-proof, assuming xelatex will be fixed at some point..

Or does anyone has a better solution?

share|improve this answer
add comment

If you're working with R, it might be you have forgotten to setEPS() before postscript('...').

I had the exact same issue.

share|improve this answer
add comment

I had a similar problem. Fixed it with the program I was using to generate the original EPS. I was working with R and added a horizontal=FALSE inside postscript(). My suggestion is to find a similar option. You don't want to rasterize the image. It defeats the purpose of using EPS.

share|improve this answer
    
Welcome to TeX.sx! –  texenthusiast Apr 11 '13 at 15:20
add comment

I bet you are creating the EPS from gnuplot, if so use

set terminal postscript enhanced eps

and your EPS and converted will have the correct orientation when included in the document.

(source: http://mathewpeet.org/howto/rotate-postscript/)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.