Path: utzoo!attcan!uunet!husc6!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: <8812221439.AA12314@EXPO.LCS.MIT.EDU>
Date: 22 Dec 88 14:39:44 GMT
References: <8812211720.AA11260@adt.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 29


    As a developer, I call for a change or extension to the X protocol to
    correct this.

I hear a complaint, but I don't hear a proposal.  If you're willing to take
the time to write down a detailed semantic description of what you want, take
a shot at a syntactic description, identify incompatibilities with the current
protocol, and include a rationale as to why the benefits of those
incompatibilities outweigh the disadvantages, I'm certainly willing to listen.

I don't think I've ever seen a well-defined semantics for "border+interior".
I know PHIGS has edge/hollow/interior stuff, but I've never seen a PHIGS spec
that managed to really give precise semantics, although I've heard the CGI
folks may be doing some work here.  I suppose I could say "your application
sounds like a great match with PEX", and that the PEX extension is capable
of supporting your fill model as well as providing server-side structure
traversal which sounds like something you could use; I don't know if that
comes anywhere near satisfying you.

The X model doesn't really have "borders" per se.  Lines aren't borders,
they are filled polygons defined from a path.  The X fill semantics are
designed to allow seamless placement of contiguous polygons without having
pixels hit more than once.  This is viewed as a feature.  It is true
that there is hardware out there for which matching this semantics is
painful.  But, the
"obvious" alternative of leaving the semantics essentially undefined also seems
painful, from the developer's viewpoint.

Anyway, I'd be happy to get any further comments you have.