flar@bendenweyr.Eng.Sun.COM (Jim Graham) (01/11/91)
In section A.3 of the new PS Lang. Ref. Manual, it says: "In Level 1 implementations, the pathbbox operator computes a bounding box that encloses all points in the current path. In Level 2, if the path ends with a moveto, the trailing endpoint is not included in the computation." I am wondering why this change was made and how extensive it is. In particular: 1) What if there are several trailing movetos, are any of them included in the computation? 2) What if there are leading movetos, would any of them be included in the computation? 3) What if there are multiple adjacent embedded movetos, are any of those included? If the answer is that only the single last trailing moveto is ignored, then I wonder why that point is treated differently. If the answer is that none of the above described points are included in the bbox, then the documentation needs to be clarified on this matter. Anyone at Adobe care to comment? ...jim
srwmcln@windy.dsir.govt.nz (01/13/91)
In article <9924@adobe.UUCP>, taft@adobe.com (Ed Taft) writes: > This situation cannot arise. When multiple consecutive movetos are executed, > each causes the preceding one to be discarded. See the moveto operator > description. Thus, it's possible to have at most a single isolated moveto at > the end of a path. > Well that may have been what the Red book said, but on our IINT with V38 PostScript I found the following: 0 0 moveto 1 1 moveto 2 2 lineto 3 3 lineto pathbbox gave 0 0 3 3 rather than 1 1 3 3. I can only assume that in the IINT inplementation either (i) That all moveto's are kept in the path and that it is upto path operators to discard useless moveto's, which pathbbox seems not to or (ii) The path keeps track of the bbox at all times and just forgets what it says in the Red book about moveto's. But, I'm glad the 2rd edition clears up the trailing moveto problem. Clive.