Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!lll-winken!ames!ncar!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.lang.postscript Subject: Re: currentpoint != last-point-in-path after charpath??? Summary: seems like what you'd expect Message-ID: <1990Mar5.020205.7084@ico.isc.com> Date: 5 Mar 90 02:02:05 GMT References: <18088@rpp386.cactus.org> Distribution: comp Organization: Interactive Systems Corporation, Boulder, CO Lines: 35 woody@rpp386.cactus.org (Woodrow Baker) and loki@moncam.uucp (Harry Fearnhamm), talking about: > > (a) false charpath ... > ...I have > never heard of it before, but it would seem to be a very subtle bug. I'd > call it that, because to my knowlege it is not documented behavior... (Maybe it's a bug in the documentation.:-) Actually, "charpath" does what you "want" it to do with the current point in most situations. But the red book isn't explicit here, as far as I can tell. There are two ways to reason why it does what it does: - charpath works like show; it's described in terms of show. So you probably want it to behave as much like show as is reason- able. (Most real uses of charpath seem to be just fancy rendering of characters in ways you can't do with show.) That means that the current point should move by the string escapement, without regard for the generated path. - As Fearnhamm suggested, the charpath behavior maintains the useful effect that, for example: (a) false charpath (b) false charpath (c) false charpath gives the same effect as: (abc) false charpath It would be surprising if it didn't. (Splitting into multiple charpaths might happen if you had font changes in between the pieces.) So...it seems it would be most useful if the red book added a note that the current point after a charpath is the same as if the corresponding show had been executed. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Don't lend your hand to raise no flag atop no ship of fools.