[XeTeX] File name bug when using \includegraphics

[Herbert Schulz]

On Oct 8, 2010, at 1:19 AM, Heiko Oberdiek wrote:

> On Thu, Oct 07, 2010 at 10:14:42PM -0500, Herbert Schulz wrote:
> 
>> On Oct 7, 2010, at 8:28 PM, Akira Kakuto wrote:
>> 
>>> Hi,
>>> 
>>>> I found a bug related to \includegraphics. If the file name includes 
>>>> "&", it stops the compiling and does not show any useful information. I 
>>>> also found out that there was no problem with "&" in the file name when 
>>>> using pdflatex.
>>> 
>>> On windows, there was no error with xelatex for an
>>> example:
>>> 
>>> \includegraphics[width=0.8\textwidth]{m&m.eps}
> 
>> There does seem to be a problem with ghostscript 8.71, at least on Mac.
>> That seems to be where it's dying.
> 
> I can confirm the bug under Linux for files in \special{PSfile=...}.
> The problem is located in xdvipdfmx. Using the configuration
> file dvipdfmx.cfg it constructs a command line for conversion to PDF.
> The command line is then passed to the *shell* and the shell interprets
> some characters in a special way.
> 
> I strongly recommend to change the D option of dvipdfmx.def
> by adding single quotes around arguments with user input, e.g.:
> 
>  D "rungs ... -sOutputFile=%o %i -c quit"
> 
> to
> 
>  D "rungs ... '-sOutputFile=%o' -f '%i' -c quit"
> 
> Unhappily single quotes will not work in Windows, AFAIK.
> At least double quotes can/should be used:
> 
>  D "rungs ... \"-sOutputFile=%o\" -f \"%i\" -c quit"
> 
> However double quotes aren't sufficient for Linux, because they
> still allow the special interpretion of some characters.
> 
> Yours sincerely
>  Heiko Oberdiek

Howdy,

Wrong place but related... The same problem exists for automatic eps conversion using pdflatex. Is that a bug in the graphics package?

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)