A question arose on StackOverflow about how to pass arguments into a
PostScript program. And the answer there was sufficient. An unrelated
question prompted me to drag up an old program that contained a Type 3
font as an example of a small and simple font. And just now I looked
a little more closely at that old program and found some funny stuff.

So, here in our less restricted forum I hope we can explore more deeply
the issue of passing parameters or options into a PostScript program
and how to organize stuff like default values.

There are several means using Ghostscript to pass data into a PostScript program.

* Make definitions in userdict using -Dname[=token] or -Sname=string
options before the program (gs processes arguments strictly left to
right, so "before the ps program file in the command line text" is
equivalent to "before that ps program gets executed").

* Make definitions in a -c 'ps source text' option before the program.

* Make definitions in a separate options.ps file and run both files
in sequence gs options.ps program.ps

* Place objects on the stack before the program (using -c or an options
file).

* Pipe a string into gs and execute it first

echo /name (josh) def | gs - program.ps

* Compose a little "master script" that runs the program itself.

echo /name (josh) def (program.ps) run | gs -DNOSAFER -

* Pass strings in the ARGUMENTS array using the -- option.

gs -- prog-taking-args.ps string1 string2 string3

And that seems to be about it.

So, suppose we've settled on a few named parameters using
-d or -s (it really is the simplest most often), how can
we arrange to use these definitions if present but fall back
to sensible defaults otherwise? And also, maybe we should
validate them somehow.

We could use `where` to determine if a name is already defined
and make a default definition if not.

/name where {pop}{ /name (Sally) def } ifelse

But this can get cumbersome where there are a lot of options
(as in my gridcal.ps program alluded to above).

On The Other Hand,
it is sometimes simple and easy to just keep the options
in the file, right at the top. When writing one-off or
highly specialized tools that don't need a nice interface.
Or just whipping up a rough draft or testing something out.
When writing up a draft, often my "options" will even be
at the bottom of the file, after all the needed definitions.
(Moving it from the bottom to the top can be as easy as wrapping
it up in something like /main{ ... }def and calling main
at the end.)

But what if you have your option nicely grouped at the top
of the file, but you still want defaults and/or some kind of
validation? One thing I (think I) have used is to collect
the options in a dictionary, then put all the defaults in
another dictionary. Then you can use 'dict dict copy' to
replace the defaults with any definitions in the new dict
and use the resulting dict.

And that's all I've got at the moments. Anything I missed?
Does anyone do it some other way? Are some of these ways
better/worse than others for other reasons or considerations
that I have neglected?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

it is sometimes simple and easy to just keep the options
in the file, right at the top.

And in www.jdawiseman.com/placemat.html the first 726 lines are the 450 parameters and settings.

One thing I (think I) have used is to collect
the options in a dictionary, then put all the defaults in
another dictionary. Then you can use 'dict dict copy' to
replace the defaults with any definitions in the new dict
and use the resulting dict.

That’s good — I like. But having all the defaults explicitly at the top helps users, in that they can see what sort of thing could go into each parameter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)