Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!bzs
From: bzs@Encore.COM (Barry Shein)
Newsgroups: comp.windows.x
Subject: Re: A developer's view of the X fill policy
Message-ID: <4544@xenna.Encore.COM>
Date: 31 Dec 88 17:16:00 GMT
References: <8812301700.AA00316@adt.uucp> <8812302033.AA03752@EXPO.LCS.MIT.EDU>
Organization: Encore Computer Corp, Marlboro, MA
Lines: 17
In-reply-to: rws@EXPO.LCS.MIT.EDU's message of 30 Dec 88 20:33:43 GMT
Posting-Front-End: GNU Emacs 18.41.15 of Tue Jun  9 1987 on xenna (berkeley-unix)


Correct me if I'm wrong but isn't the current fill policy equivalent
to using CoordModePrevious with the first point (p0) satisfying
MIN(x,y) and adding (1,1) to p0(x,y) before filling to shift it? (I
realize not all the Fill calls use mode, but let's ignore that for the
moment)?

If that's so it seems Jim Madd's proposal to allow
FillWithinPath/FillIncludingPath or not is sound since the problem
that the protocol claims to solve now is fairly easily solved by the
above operation with FillIncludingPath whereas it's the current
approach which makes it hard to FillWithinPath for arbitrary shapes.

Like I said, I could be missing something, but I did get bit by
this also (just yesterday), the "fix" is rather ugly.

	-Barry Shein, ||Encore||