How to find if nocurrentpoint is True/False.
Arif Zaman
which does a `moveto' if there is nocurrentpoint
and does a `lineto' if the currentpoint is defined.
This would allow me to write a graph with many points
as:
x1 y1 drawto
x2 y2 drawto
...
xn yn drawto
without having the first line be any different from
the other lines.
It would be simple if there were some way I could
querry PS to find out if a currentpoint exists, but
I don't know how to do that.
Berthold K.P. Horn
To: ar...@mercury.stat.fsu.edu.fsu.edu (Arif Zaman)
In-reply-to: ar...@mercury.stat.fsu.edu.fsu.edu's message of 5 Oct 91 13:24:55 GMT
Subject: How to find if nocurrentpoint is True/False.
BCC: bkph
--text follows this line--
How about trying to do something that is illegal when the current point is
undefined - such as `lineto' - and catch it in a `stopped' context?
{2 copy lineto}stopped{moveto}{pop pop}ifelse
Rich Berlin
/nocurrentpoint? { {currentpoint pop pop} stopped } bind def
-- Rich
Bakul Shah
>I often need to use a function, call it `drawto'
>which does a `moveto' if there is nocurrentpoint
>and does a `lineto' if the currentpoint is defined.
/drawto { % x y
{currentpoint pop pop} stopped
{moveto}{lineto} ifelse
} bind def
But this is kind of slow. Okay for experimenting but surely your
PS generator program can keep track of whether the currentpoint is
defined and generate appropriate code?
Vidiot
If you do a "currentpoint" query and the x/y points are empty, you will
get an error. I don't see anything in the new book that will let you get
away with dowing what you want.
But, you can redefine the moveto, stroke, etc procedures to that it will set
a flag for you. Then you design your drawto procedure to look at the flag.
If it isn't set, it calls moveto, which moves to the point and set the flag.
Otherwise it does a lineto. Then when a stroke is done, the flag is reset.
--
harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown
Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown
rutgers/ INTERNET:vidiot!brown%astroa...@spool.cs.wisc.edu
ftms!br...@uu2.psi.com
Kate McDonnell
I'm using Aldus Freehand to generate some graphics on the Mac,
and can export EPS files. Now I need to convert these to GIF
format. Is there a converted, preferably public domain, that
allows this?
Please e-mail and I will summarize.
Thanks very much
Kate McDonnell
gre...@ozrout.uucp
Jim Rudolf
><I often need to use a function, call it `drawto'
><which does a `moveto' if there is nocurrentpoint
><and does a `lineto' if the currentpoint is defined.
>If you do a "currentpoint" query and the x/y points are empty, you will
>get an error. I don't see anything in the new book that will let you get
>away with dowing what you want.
How about this:
/drawto { % x y --
{currentpoint} stopped {
moveto
} {
pop pop lineto
} ifelse
} def
-- Jim
--
Jim Rudolf
The Turing Institute
rud...@turing.ac.uk
Robert A. Lerche
Several people have pointed out that surrounding "currentpoint" with
a "stopped" operator allows a program to catch a "nocurrentpoint"
error and hence detect whether the current point exists. The examples
posted omit a minor point, however.
The usual operation of an error handling procedure includes setting
"newerror" in the "$error" dictionary to true. This indicates that a
new error has occurred. The standard "handleerror" procedure sets it
back to false and reports the error.
When a program catches an error via "stopped", the standard
"handleerror" procedure isn't called and hence "newerror" isn't
cleared. Here is an example that fixes this (minor) problem.
/iscurrentpoint? {
{currentpoint pop pop} stopped dup
{$error /newerror false put} if
not
} def
This returns a true if there is a current point, or a false if not,
and clears the "newerror" flag.
By the way, it's possible for "currentpoint" to return a stack
overflow or undefined result error, not just a no current point error.
It's probably not worth bothering about these.
C.E. Thompson
>
>By the way, it's possible for "currentpoint" to return a stack
>overflow or undefined result error, not just a no current point error.
>It's probably not worth bothering about these.
The "stopped" construction could also trap "execstackoverflow", or "timeout",
or "interrupt", or maybe other errors I haven't thought of. It would be a
great deal cleaner to specifically trap the "nocurrentpoint" error.
Chris Thompson
JANET: ce...@uk.ac.cam.phx
Internet: ce...@phx.cam.ac.uk
C.E. Thompson
>
>The "stopped" construction could also trap "execstackoverflow", or "timeout",
>or "interrupt", or maybe other errors I haven't thought of. It would be a
>great deal cleaner to specifically trap the "nocurrentpoint" error.
But it would be cleaner still to avoid using error trapping at all. The
following procedure will return 'true' or 'false' according to whether
there is a current point or not:
/testcurrentpoint {
false mark {cleartomark not mark exit} dup dup dup pathforall pop
} def
Perhaps it is also worth commenting that the original requirement is a
little strange. Most PostScript-generating applications know what state the
current path is in at all times.
Arif Zaman
>little strange. Most PostScript-generating applications know what state the
>current path is in at all times.
Actually I have often found the a lineto which functioned as a moveto
would greatly simplify programming many kinds of graphs. Applications
may know, if fact even I know, what the state is, but it makes for
cumbersome programming. For example, if I want to draw a line graph
connecting (x,f(x)) for x=1,...,100:
(I am calling this psuedo-lineto as jointo here. I forgot
what I called it in my original posting.)
100 { ..compute x and f(x).. jointo } repeat
is much nicer than
1 f(1) moveto
99 { ..compute x and f(x).. jointo } repeat
This is especially so if f is some very complicated function which is
needed only once. In the first method, one can just write out the
operation in the {..} before repeat, but in the second case the only
sensible way would be to define f and then use it in the two separate
occurances. I see no more elegant way than the jointo operator, which
I use knowing full well the state of the current path!
Jim Graham
|> >Perhaps it is also worth commenting that the original requirement is a
|> >little strange. Most PostScript-generating applications know what state the
|> >current path is in at all times.
|>
|> Actually I have often found the a lineto which functioned as a moveto
|> would greatly simplify programming many kinds of graphs. Applications
|> may know, if fact even I know, what the state is, but it makes for
|> cumbersome programming. For example, if I want to draw a line graph
|> connecting (x,f(x)) for x=1,...,100:
|>
|> (I am calling this psuedo-lineto as jointo here. I forgot
|> what I called it in my original posting.)
|>
|> 100 { ..compute x and f(x).. jointo } repeat
|>
|> is much nicer than
|>
|> 1 f(1) moveto
|> 99 { ..compute x and f(x).. jointo } repeat
How about:
/moveto cvx 100 { .. compute x and f(x) .. exec /lineto cvx } repeat pop
...jim