Hironobu-san :
> Philip's problem is pdf inclusion. Current (x)dvipdfmx does not support > /Rotate at all, so inclusion of pdf with /Rotate command fails. > Yes, Adobe Acrobat (and Preview.app in OS X) adds /Rotate command in PDF > rotation, so these PDFs are out-of-support by (x)dvipdfmx. Thank you. (Sort of) understood, but I am now unclear how, if (x)dvipdfmx does not support /Rotate, XeTeX is nonetheless able to communicate to xdvipdfmx that a figure included using \XeTeXpdffile with a non-zero value for the "rotated" keyword is to be rotated. Presumably the "pre-treatment" to which you referred actually applies co-ordinate transformation to the input file and generates an entirely different (actually rotated, not merely "flagged as to be rotated") PDF, but does XeTeX do the same internally, or does it have some other mechanism by which it can indicate to xdvipdfmx that a particular figure is to be rotated ? What is odd is that it clearly has the ability to cause a figure to be rotated, yet it does not look inside the PDF to see if it contains /Rotate and then take appropriate action, but instead requires the user to add a specific "rotated" keyword:value pair. But that is probably a question for the XeTeX list, and not relevant to the TeX Live discussion here. ** Phil. -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
