Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: A developer's view of the X fill policy
Message-ID: <8812311720.AA25597@EXPO.LCS.MIT.EDU>
Date: 31 Dec 88 17:20:21 GMT
References: <8812302241.AA06577@adt.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 48


    considering the
    description of each in the manual, this is not surprising -- it reads
    very much like IBM's _Principles_Of_Operation_

Documenting this stuff is hard.  If you have constructive suggestions
(viz. prose) for improving it, by all means send it to us.

    With this in mind,
    perhaps we should make a new GC field, say border_fill, with possible
    values FillWithinPath, FillIncludingPath, and FillPartialPath

So now I'll get to second-level semantics.  Are you sure you don't care
that this tracks the line-width, that you're only interested in essentially
one-pixel wide borders?  (Have you ever seen a one-pixel wide line on a
MegaScan display?  I've drawn one, but I haven't seen it :-)  Are you
sure you don't want "inside" to mean "not including the pixels that would
be drawn by the path outline using the current line-width"?  Or are you
sure that you wouldn't also like the capability of having the "outline"
start at the path and go "outwards", rather than being centered on the
path?  I'm describing things that are rather difficult to implement, but
again, I'm trying to make sure your proposal actually matches what you
think you're actually proposing, and that you're satisfied with the way
it turns out.

    >Can you explain
    >what "adjustments" I make to achieve that (I really don't want to have to
    >figure out how to decompose polygons to achieve it).
    Consider that I'm in exactly the same place.

Fine.  At least we now both understand that neither has "the" right answer.

    Silicon Graphics' hardware follows many of the X rules but would have
    real problems with the X polygon fill definition.  I think the only
    way they'd be able to make use of their hardware currently would be to
    cause a fill inside a path and then draw the edges that X would have
    filled.

I'm not sure this answered my question.  Are you sure their hardware defines
"inside" the same way?  Are you sure they don't, for example, define the
polygon edges with Bresenham lines?

    It is common to deal with shapes as objects
    and to allow them to be bordered, unbordered, or have the border a
    different color than the region it contains.

Yes, but as I've said, I've yet to see a crisp definition (agreed to
by many parties) of what constitute "borders" for objects.