CODEWITHSUNDEEP
node.jspdfghostscript
Daniel
Daniel

Reputation: 2777

Ghostscript command line - pass arguments to included file

I developing pdf conversion app with node.js and Ghostscript. I execute command line gs with exec(). My command definition looks like:

let gs_cmd = `
               gs -sDEVICE=pdfwrite \
                  -dPDFX=true \
                  -dPDFACompatibilityPolicy=1 \
                  -sColorConversionStrategy=/CMYK \
                  -sProcessColorModel=DeviceCMYK \
                  -sDefaultCMYKProfile=${icc_profile_file} \
                  -dNoOutputFonts \
                  -dBATCH \
                  -dQUIET \
                  -r${DPI} \
                  -g${w}x${h} \
                  -dPDFFitPage \
                  -NumRenderingThreads=4 \
                  -o ${target_file}-conv.pdf \
                  PDFX_def.ps \
                  @trimbox.in "Trimed" \
                  ${target_file}.pdf
            `;

I have problem with line:

@trimbox.in "Trimed" \

which tells to Ghostscript to include file and pass the parameters to in. I can't find a proper way to include parameters that can be used in included file. I want to pass "Trimed" string as $0 argument which will be available in trimbox.in file. I also tried with -t=Trimmed or -t="Trimmed" without effects.

From Ghostscript docs (section 10.1):

@filename

Causes Ghostscript to read filename and treat its contents the same as the command line. (This was intended primarily for getting around DOS's 128-character limit on the length of a command line.) Switches or file names in the file may be separated by any amount of white space (space, tab, line break); there is no limit on the size of the file.

-- filename arg1 ...
-+ filename arg1 ...

Takes the next argument as a file name as usual, but takes all remaining arguments (even if they have the syntactic form of switches) and defines the name ARGUMENTS in userdict (not systemdict) as an array of those strings, before running the file. When Ghostscript finishes executing the file, it exits back to the shell.

How to achieve this?

Running my command causes error:

Error: /undefined in Trimed

Upvotes: 1

Views: 2264

Answers (1)

KenS
KenS

Reputation: 31199

Firstly you should review the Ghostscript licence to ensure your use is compliant with the licence (AGPL v3). Note that this includes software as a service applications.

"Trimed" isn't a Ghostscript switch and it isn't the name of an input file, so yes, you get an error. You can't 'pass parameters' to @file, because Ghostscript treats that, literally, as a file containing a bunch of switches. There is no command substitution or anything like that. SO you can't have $0 in the file specified by @file.

So when you say :

@PDFX_def_trimbox.ps "Trimed" \

which tells to Ghostscript to include file and pass the parameters to in

I'm afraid you are incorrect. There is no way to 'pass parameters' to the file when using the @file syntax.

You haven't said what's in the file 'PDFX_def_trimbox.ps', and I'm suspicious (because of the .ps) that this is a PostScript program. You can't use a PostScript program with the @file syntax, because a PostScript program is not a series of Ghostscript switches.

So where you have :

-sDEVICE=pdfwrite \
-dPDFX=true\

etc, you could put all of those switches into the file specified by @file. But you can't put any PostScript in there.

There are a few other problems. You have specified NumRenderingThreads=4, which will do nothing, because the pdfwrite device doesn't (in general) do any rendering, it preserves the input as far as possible as vector data. So pdfwrite ignores this parameter altogether.

For similar reasons, the -r parameter is less than useful. In the case of pdfwrite that simply affects how accurate the conversion is. You shouldn't set that without good reason.

You've set -sColorConversionStrategy=/CMYK when it should be =-sColorConversionStrategy=CMYK or -dColorConversionStrategy=/CMYK. -s takes strings, -d takes numbers or names.

-g sets the width and height of the page in pixels, which isn't a great plan, that depends on the resolution. You should use -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS instead, and not set the resolution.

Edit

In response to a comment below.

If you want PDF file to contain a 300 dpi image, then you need to create a page which is the correct size so that, when drawn on it, the bitmap data form the image is 300 dpi.

So for example, if you have an image which is 600 pixels by 900 pixels, then in order to get that to be 300 dpi you must make the media size 2 inches by 3 inches, which is 144 by 216 points. Changing the resolution of the pdfwrite device won't affect that at all. Setting -g and -r will alter the media size, but not the resolution of the image, though if you also set -dPDFFitPage then yes it will rescale the image to fit the media, which will alter its resolution.

I have no idea if your original image was 300 dpi, if it was, and the SVG to PDF conversion maintained that, then you don't need to mess about with media sizes and resolution at all, the pdfwrite device will maintain whatever was there.

As regards the @file syntax, you cannot do this:

-c "[ {ThisPage} << /TrimBox [$0 $1 $2 $3] >> /PUT pdfmark"

in the file supplied via the @ comamnd because, as I said, there is no variable replacement in the processing which Ghostscript does on the contents of that file. This is not a bash script.

Upvotes: 1

Related Questions