W3C home > Mailing lists > Public > www-svg@w3.org > May 2002

RE: fill-rule problem ..

From: Craig Brown <cmb@research.canon.com.au>
Date: Mon, 06 May 2002 11:18:53 +1000
To: <ronan@roasp.com>
Cc: "Goessner / MecXpert" <goessner@mecxpert.de>, "Craig Brown" <cmb@research.canon.com.au>, <www-svg@w3.org>
Message-Id: <20020506005304.735438B10@bellmann.research.canon.com.au>
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 Sunday, 5 May 2002 21:19:37 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:22 GMT