Path: utzoo!attcan!uunet!snorkelwacker!apple!bionet!agate!saab.stanford.edu!neon!lucid.com!jwz
From: jwz@lucid.com (Jamie Zawinski)
Newsgroups: comp.lang.postscript
Subject: transfer function (was Re: Help!)
Message-ID: <JWZ.90Sep28150050@kolyma.lucid.com>
Date: 28 Sep 90 22:00:50 GMT
References: <265@pb2esac.UUCP> <JWZ.90Sep13112918@kolyma.lucid.com>
	<20829@well.sf.ca.us>
Sender: jwz@lucid.com
Organization: Lucid, Inc., Menlo Park, CA
Lines: 23
In-reply-to: shiva@well.sf.ca.us's message of 28 Sep 90 18:43:41 GMT

In article <20829@well.sf.ca.us> shiva@well.sf.ca.us (Kenneth Porter) writes:
>
> As Jamie Zawinski points out, settransfer can also be used,
> but you should modify his example to concatenate the new
> transfer proc with the result of currenttransfer, so that
> the result can be combined with previous transfer ops (the
> most important being any builtin engine compensation).

Hmm, how would you do that?  I don't think

	{ { currenttransfer exec 1 exch sub fade-factor mul 1 exch sub } 
	  settransfer }

will work, because currenttransfer is going to return the currently-executing
procedure, leading to infinite recursion.  You could do something like

	/saved-transfer currenttransfer def
	{ { saved-transfer 1 exch sub fade-factor mul 1 exch sub }
	  settransfer }

but that doesn't seem especially foolproof.

		-- Jamie