Hi Tod,

First thing I have is an observation.

It appears to me that the psfmtdrv command you have stated is not correct if you are really expecting a PDF (.pdf) file as a result. Unless you've not given the command correctly or not given it in it's entirety.

So if the command you've stated is incomplete, then you'll have to be more exact in what is the command in order to get back a meaningful response.

All I would expect from the command you've stated is a PS (.ps) result, because the command as stated does not include the -distill option. But this command you've given will not produce a PDF result (unless you have something else in your script that follows that's producing a PDF from the PS output file). The -pdfusegs option tells psfmtdrv to use the XPP delivered 'gs' command as the distiller (PS to PDF) - but it only does that if the -distill option is also specified.

The second thing I observe is that the argument to the -pn option does not seem to me that it would be correct, if indeed it does contain a slash (/) in it (i.e. -pn /our_custom_file). As I understand it, the argument to -pn should be just a filename (not a path), and can also contain % arguments in it as shown in the documentation (e.g. %j for JOB name and %d for DIV name). The path (where there would be slashes) where the destination file is written is specified with the -df option.

• I'm not sure what "debugging" you're trying to do. Using strace will trace all the system calls, but I doubt that will help you much. If you can capture the real full command that is being run by your script, then running the exact same command manually via the command line along with adding the -X option (extra process messages) might help.
• With the right options, psfmtdrv will use 'gs' to generate the PDF. If you add the -X option to the psfmtdrv command, I believe it will spit out an extra message saying what is the 'gs' command it runs to create the PDF from its PS output.
• I don't understand your third question. It almost seems to imply that the "default" for your process is to use Acrobat Distiller to produce the PDF, and not 'gs' (Ghostscript), since you seem to be asking if using Ghostscript is a better way to generate the PDF. Maybe you can clarify your third question.

Jonathan,

Thank you for your comments.

The root of the problem was the difference between the -distill and -pdfusegs flags fed to the psfmtdrv.  From the command line PDF manual:

–pdfusegs

Distill to PDF using Ghostscript.

This overrides any distiller choice

specified by file or environmental

variable.

–distill

After creating a PostScript (.ps) file,

invoke the Adobe Acrobat Distiller

program to create a Portable

Document Format (PDF) file with a

.pdf extension. See the –pdfmark, the

–pdfps spec, and the –pn filename

switches below.

We do not use Adobe Distiller but instead rely on Ghostscript.  These two seem to contradict each other until you realize that using -distill with the -pdfusegs flag overrides the Adobe Distiller ONLY if you have already specified -distill.  By contrast.the wording reported by Xyhelp:

-pdfusegs

When creating PDF output, use Ghostscript. This requires the

-distill switch. If neither -pdfuseacro nor -pdfusegs is

specified, XPP uses the installation default.

... is more specific.  We relied on the pdf manual and only saw the Xyhelp description later.

Thanks again for your help.

Hi Tod,

Ah, yes, I can see how it could be a bit confusing from what's stated in the Command Line Utilities manual.

Perhaps we can tweak that for a future version of cmdutils.pdf to make it match more closely how it's described in the online xyhelp file.

Thanks you very much for letting us know what was the source of confusion.