Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.postscript > #3456

How do you organize options or global parameters to a ps program?

Newsgroups comp.lang.postscript
Date 2019-09-20 21:00 -0700
Message-ID <adeb2970-5cb9-4541-952e-be1a98c723b9@googlegroups.com> (permalink)
Subject How do you organize options or global parameters to a ps program?
From luser droog <luser.droog@gmail.com>

Show all headers | View raw


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?

Back to comp.lang.postscript | Previous | NextNext in thread | Find similar


Thread

How do you organize options or global parameters to a ps program? luser droog <luser.droog@gmail.com> - 2019-09-20 21:00 -0700
  Re: How do you organize options or global parameters to a ps program? jdaw1 <jdawiseman@gmail.com> - 2019-10-10 06:36 -0700

csiph-web