(Maybe I should change the subject: topic is completely different from original one.)
All the effect which is caused by change in dvipdfmx.cfg yesterday, that is, -dAutoRotatePages=/None, is suppression of unnecessary /Rotate warning in eps inclusion (, and also may be suppression of potential 'real' rotation in the future dvipdfmx which supports /Rotate): no change in output so far. And now the topic is about support of /Rotate already existing in pdfs: > The Stack Exchange message suggests : > > pdfcrop foo.pdf foo-new.pdf > > which I will try should the problem arise again. Good information! pdfcrop calls pdfTeX internally, and pdfTeX supports /Rotate: so pdfcrop can be a useful alternative of gs for 'pre-treatment'. Thank you Philip. And one more question arises: We don't get any warnings in inclusion of pdf which has /Rotate: XeTeX says nothing, and xdvipdfmx says nothing because default output-driver is 'xdvipdfmx -q -E' in TL2015. I think this is harmful, because there is no chance for users to notice unrotated figures before they see output directly. At least in TL2014 xdvipdfms shows warning like "<< /Rotate 90 >> found. (not supported yet)" Can anyone explain when, and why, the warning message is suppressed? And I'd like XeTeX to support /Rotate in pdf too ;) Thanks, Hironobu
-------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
