RE: fill-rule problem ..

Thanks all for setting me straight on this.

Ronan

§-----Original Message-----
§From: Craig Brown [mailto:cmb@research.canon.com.au]
§Sent: Monday, May 06, 2002 3:19 AM
§To: ronan@roasp.com
§Cc: Goessner / MecXpert; Craig Brown; www-svg@w3.org
§Subject: RE: fill-rule problem ..
§
§
§Ronan,
§
§This is exactly how SVG odd-even and non-zero winding work.
§
§...cmb
§
§--Original Message--:
§>Please excuse my interjection on this thread. I've been loosely
§following it
§>for a while and have had a general question about it in mind since the
§>beginnnig...
§>
§>Pardon my naivety on the subject, but I remember in mathematics at
§>university that this was all well covered using the property of
§positiveness
§>of surfaces or faces.
§>(Please pardon my sketchy memory, I might have this 100% backwards)...
§>
§>On a plane, the direction of the line (with respect to the normal of the
§>plane) defining a boundary between two sides of closed boundaries cab ne
§>defined as a positive (inside) boundary or negative (outside) boundary
§>depending on whether the line is clockwise or counterclockwise
§the enclosed
§>region.
§>
§>IE
§>to define a donut, you drew a cw outer circle and a ccw inner circle. This
§>defines the region between the two faces as 'inside' that
§boundary pair. If
§>the directions were reversed, then the 'inside' the entire plane
§except the
§>region between the two curves, which was outside.
§>
§>With this absolute definition of inside and outside, you never
§have to worry
§>about filling problems.
§>
§>I realize we have a partial implementation of this in paths but could this
§>not be generalized for all entities?
§>
§>I'm confused why SVG did not go with such a model in the first place.
§>
§>Ronan
§>
§>§-----Original Message-----
§>§From: www-svg-request@w3.org [mailto:www-svg-request@w3.org]On Behalf Of
§>§Goessner / MecXpert
§>§Sent: Sunday, May 05, 2002 4:49 PM
§>§To: Craig Brown
§>§Cc: www-svg@w3.org
§>§Subject: Re: fill-rule problem ..
§>§
§>§
§>§hi craig,
§>§
§>§> Lads,
§>§>
§>§> The problem with all this stuff is the implementation.
§>§>
§>§> Imaging the situation where you have a U...
§>§>
§>§> Do you fill inside the U?
§>§>
§>§> If the answer is NO - think about the case where the top of
§the U touch.
§>§> Now - do you fill?  I assume the answer for a proposed "always" fill is
§>§> YES.
§>§>
§>§> Glitch is now you can't do scan-line rendering.  A scanline at
§the top of
§>§> the U effects the result for a scanline in the middle of the U.
§>§
§>§.. hmm .. i believe i understand.
§>§with scan-line rendering, i.e. drawing a ray from any point on the
§>§canvas to
§>§infinity in any direction and counting the number of path
§segments that the
§>§ray crosses, we cannot implement an fill-rule="always".
§>§
§>§> In reality - it is usually very easy to modify the content to get the
§>§effect
§>§> required rather than adding 2d complexity to filling.
§>§
§>§so an ever working method would be, to draw the U (or any open
§shape) *and*
§>§draw it reverse again back to its subpath initial point. then - with both
§>§rules 'evenodd' and 'nonzero' - the cross-counting works reliable,
§>§since the
§>§segments were counted twice.
§>§
§>§based on these thoughts following algorithm should be quite easy to
§>§implement:
§>§
§>§1) don't close open subpathes automatically.
§>§2) count closed subpath segments once and open subpath segments
§>§twice - with
§>§different directions.
§>§
§>§what do you think?
§>§--
§>§stefan goessner
§>§
§>§> ...cmb
§>§>
§>§> --Original Message--:
§>§> >It occurred to me that it might be useful to be able to specify
§>§more than
§>§> >one color for fill, to alternate the color according to different
§>§> >fill-rules. For instance:
§>§> >
§>§> ><polygon points="100,20 165,196 26,87 176,87 42,198 "
§>§style='stroke:blue;
§>§> >fill:yellow,blue; fill-rule:evenodd;'/>
§>§> >
§>§> >would give a star with yellow arms and a blue center.
§>§> >
§>§> >This might also be used to completly fill an enclosed area, by
§>§specifying
§>§> >the same color twice.
§>§> >
§>§> >Just an idea-
§>§> >-Doug
§>§> >
§>§> >
§>§> >> -----Original Message-----
§>§> >> From: www-svg-request@w3.org
§[mailto:www-svg-request@w3.org]On Behalf
§>§Of
§>§> >> Goessner / MecXpert
§>§> >> Sent: Friday, May 03, 2002 4:46 AM
§>§> >> To: www-svg@w3.org
§>§> >> Subject: Re: fill-rule problem ..
§>§> >>
§>§> >>
§>§> >> A solution to this problem might be an additional fill-rule, perhaps
§>§> >>
§>§> >> fill-rule="always"
§>§> >>
§>§> >> --
§>§> >> stefan
§>§> >>
§>§> >>
§>§> >>
§>§> >> > i simplified the path to a square with a "V" in it.
§>§> >> >
§>§> >> > <svg width="300" height="200">
§>§> >> >   <path id="A" transform="translate(20,20)" stroke-width="2"
§>§> >> stroke="blue"
§>§> >> > fill="lightgray" fill-rule="nonzero"
§>§> >> >         d="M0,0 H100 V100 H0 Z M10,50 50,90 90,50" />  <!--
§>§clockwise
§>§/
§>§> >> > counterclockwise -->
§>§> >> >   <path id="B" transform="translate(140,20)" stroke-width="2"
§>§> >> stroke="blue"
§>§> >> > fill="lightgray" fill-rule="nonzero"
§>§> >> >         d="M0,0 H100 V100 H0 Z M90,50 50,90 10,50" />  <!--
§>§clockwise
§>§/
§>§> >> > clockwise -->
§>§> >> > </svg>
§>§> >> >
§>§> >> > 1) if a (sub)path is not closed, an invisible closepath from the
§>§> >> (sub)path's
§>§> >> > current point to its initial point is used for filling.
§>§> >> > 2) if one path contains the other completely the fill-rule
§>§determines
§>§if
§>§> >> the
§>§> >> > subpath has to be filled or not.
§>§> >> > 3) fill-rule="nonzero" (the default) will
§>§> >> >    a) fill the inner subpath, if it has the same
§(angular) direction
§>§as
§>§> >> the
§>§> >> > outer subpath.
§>§> >> >    b) not fill the the inner subpath, if its angular direction is
§>§> >> different
§>§> >> > to the outer subpath's.
§>§> >> > 4) fill-rule="evenodd" will never fill the inner subpath
§>§> >> >
§>§> >> >
§>§> >> > it is conform to the SVG 1.1 spec, that there is *no way*
§>§to fill the
§>§> >> square
§>§> >> > in path (id="A") completely.
§>§> >> > the path can be modified (id="B")to match point 3a) above. But
§>§> >> in case of
§>§> >> an
§>§> >> > "N"-shaped subpath instead of a "V" that wouldn't help either.
§>§> >> > --
§>§> >> > stefan
§>§> >> >
§>§> >> >
§>§> >> > ----- Original Message -----
§>§> >> > From: "Doug Schepers" <doug@schepers.cc>
§>§> >> > To: "Goessner / MecXpert" <goessner@mecxpert.de>
§>§> >> > Sent: Wednesday, May 01, 2002 2:24 PM
§>§> >> > Subject: Re: fill-rule problem ..
§>§> >> >
§>§> >> >
§>§> >> > > Could this be a bug in ASV3?  I got it to render as solid once,
§>§after
§>§> >> > > refreshing a couple of times, and once got a blue artifact
§>§> >> line straight
§>§> >> > > from (50,50) to (90,50). [WinMe/IE6/ASV3]
§>§> >> > >
§>§> >> > > What is the logic behind it not filling the square with gray? No
§>§lines
§>§> >> are
§>§> >> > > being crossed. Do I misunderstand the fill rule?
§>§> >> > >
§>§> >> > > -Doug
§>§> >> > >
§>§> >> > > ----- Original Message -----
§>§> >> > > From: "Goessner / MecXpert" <goessner@mecxpert.de>
§>§> >> > > To: <www-svg@w3.org>
§>§> >> > > Sent: Wednesday, May 01, 2002 5:48 AM
§>§> >> > > Subject: fill-rule problem ..
§>§> >> > >
§>§> >> > >
§>§> >> > > > i have a simple square with two quadratic bezier segments
§>§> >> in it. it is
§>§> >> > > easy
§>§> >> > > > to define this by a single path element.
§>§> >> > > >
§>§> >> > > > <svg>
§>§> >> > > >   <path transform="translate(20,20)" stroke-width="2"
§>§stroke="blue"
§>§> >> > > > fill="lightgray"
§>§> >> > > >         d="M0,0 H100 V100 H0 Z M10,50 Q30,30 50,50 T90,50" />
§>§> >> > > > </svg>
§>§> >> > > >
§>§> >> > > > but i cannot find a fill-rule to completely fill the
§>§> >> square. even the
§>§> >> > new
§>§> >> > > > winding-count rule wouldn't work.
§>§> >> > > >
§>§> >> > > > --
§>§> >> > > > stefan goessner
§>§> >> > > >
§>§> >> > > >
§>§> >> > >
§>§> >> >
§>§> >>
§>§> >>
§>§> >
§>§> >
§>§> >
§>§> >
§>§> --
§>§> Craig Brown      Principal Software Engineer
§>§> Canon Information Systems Research Australia     Phone: 61 2 9805 2649
§>§> 1 Thomas Holt Drive,  North Ryde,  NSW 2113.     Fax:   61 2 9805 2929
§>§>
§>§
§>§
§>
§>
§>
§>
§--
§Craig Brown      Principal Software Engineer
§Canon Information Systems Research Australia     Phone: 61 2 9805 2649
§1 Thomas Holt Drive,  North Ryde,  NSW 2113.     Fax:   61 2 9805 2929
§
§

Received on Monday, 6 May 2002 18:11:20 UTC