On 2014-08-27 18:49, maxwell wrote:
On 2014-08-27 18:16, Jonathan Kew wrote:
I'm curious why Ghostscript is being run at all. Is it trying to
convert a PostScript or EPS graphic, when you intended to use a PDF
directly? Maybe one of the users has a different version of the
graphics package, or even just a configuration file, in a personal
location? Does one of the users have a pre-converted .pdf version of
the graphic, but the other only has access to an .eps original?
I think I've figured this out.
We embed a few PDF images in our documents. We had had a similar crash
problem earlier when embedding newer versions of PDFs (v1.6)--apparently
xdvipdfmx prefers older versions of PDFs. (PDF v1.6 corresponds to
Adobe v7, and I think the xdvipdfmx.cfg file specifies v5 = v1.4. But I
haven't studied that .cfg file.)
With advice from people here (see this thread:
http://tug.org/pipermail/xetex/2010-August/017806.html), we had overcome
the problem by specifying to xdvipdfmx that it use a newer version of
ghostscript (9.06 instead of 8.71) on the final pass (where it builds a
PDF), and specifying the '-no-pdf' parameter on the earlier passes.
However, I had put this latter parameter on the wrong side of the input
file name, i.e.
xelatex foo.tex -no-pdf
instead of
xelatex -no-pdf foo.tex
so it was still trying to build a PDF in the earlier passes using the
default version of ghostscript. And apparently the default ghostscript
was different on the other user's machine from mine, causing the crash.
Moral of the story: command line parameters go *before* the input file.
Duh.
Thanks for the help in tracking this down!
Mike Maxwell
--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
