I removed the stroke_opacity entity completely. Bert also pointed out that I was accidentally setting stroke_opacity on stroke elements that had the fill color. This fixes that glitch as well. Of course, that fixed, I do recognize that in the cases where a stroke is rendered in fill color, there may be some potential oddities in the rendering. As it's now been proven that people do have use for this, perhaps we we'll opt to keep the "hack" and forget the opacity completely.<br>
<br>I guess I'm going to ponder this and bring it up with the other developers for the next day or so before finalizing it on the wiki. Sorry for the delay, but thanks for all the discussion! It's been really helpful. Please let me know if you find any more bugs or have ideas for new features the script could handle to make things easier.<br>
<br>- Eben<br><br><br><br>On Tue, Mar 18, 2008 at 4:13 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br>> On Tue, Mar 18, 2008 at 3:47 PM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> > On Mar 18, 2008, at 19:20 , Eben Eliason wrote:<br>> ><br>> > > Again, this is usually the fault of the stroke translucency,<br>> > > since the stroke overlaps the fill by half its width, causing a<br>
> > > layered effect. Our only potential uses for this are (opaque stroke,<br>> > > translucent fill) and (translucent stroke, transparent fill). That<br>> > > is, at no time will we ever use a translucent stroke in conjunction<br>
> > > with any fill at all, which is where you run into odd looking results.<br>> ><br>> ><br>> > Unless some icon designer used the (now translucent) fill color for a<br>> > stroke. Or let strokes overlap, which will look odd as well.<br>
> ><br>> > That, and the fact that alpha-blending will take more cycles than<br>> > using solid colors, is that not enough reason to ditch that opacity<br>> > idea? If you insist on it, icon designers will have to make sure their<br>
> > strokes won't ever overlap, which can of course be achieved by boolean<br>> > geometry, but this is much harder to do correct than what is required<br>> > now.<br>> <br>> I can remove the stroke-opacity altogether. As mentioned before, I<br>
> don't have any particular goal in mind with respect to that<br>> property...I just implemented it at the same time as fill-opacity<br>> because it was easy to add. I do want to keep the fill-opacity so we<br>
> can take advantage of it in the future, though. It is something that<br>> may not be implemented immediately, but would make the code much<br>> cleaner once we are able to support it.<br>> <br>> - Eben<br>
> <br><br>