[Clipart] transparent turkeys

[Jon Phillips]

Stephen Silver wrote:
> Jonadab the Unsightly One wrote:
> 
> 
>>"Stephen Silver" <ocalocal at btinternet.com> writes:
>>
>>
>>>OCAL has a number of SVG files with unintended partial transparency.
>>>This is due to Inkscape bugs #875906 (which causes fill-opacity to be
>>>ignored in some situations) and #1003385 (which ensures that those
>>>situations are frequent).  These bugs afflict Inkscape 0.39, and maybe
>>>some earlier versions too.
>>
>>Interesting.  Here I was thinking it was a regression in 0.40 that
>>rendered SVGs incorrectly that appeared correct in previous versions.
> 
> 
> If I want to know what an SVG file really looks like, I look at it in the
> Batik and Adobe viewers.  In this case they both say that Inkscape 0.39 is
> wrong.
> 
> 
>>Additionally, I've in some instances been having difficulty getting
>>Inkscape 0.40 to make these objects properly opaque -- if I open one
>>of them, select the object in question, bring up its fill properties,
>>and edit the color or gradient, it sometimes appears to be fully
>>opaque on the fill-and-stroke dialog but does not render that way on
>>the object itself.
>>
>>For example, in the image thanksgiving_spread_01.svg, if I select the
>>turkey, and ungroup it, and select then the main body of the turkey
>>(not the leg), and bring up fill-and-stroke, the alpha value of the
>>fill color is set to 255.
> 
> 
> You're still in a group (that was within the group that you just ungrouped),
> and this has the default SVG properties (opaque black fill, no stroke).
> But these properties have no effect on the image, because each object in the
> group specifies its own properties, which override the group properties.
> 
> 
>>Hey, wait -- that's not all.  If I attempt to change any aspect of the
>>fill color, it's suddenly black, instead of the color it was.  Upon
>>closing (without saving) and reopening, I discover that, in fact, it
>>was set to black all along, in the fill and stroke dialog, as if one
>>part of Inkscape 0.40 (the rendering part) "knows" the correct hue and
>>saturation and value, and another part (the fill and stroke dialog)
>>"knows" the correct opacity, but never the twain shall meet, or
>>something.
> 
> 
> If you edit the group properties, Inkscape passes them on to everything
> in the group.  It's the same in Inkscape 0.39.  It's a bit surprising,
> although I think I now see why it's done this way.
> 
> If you ungroup this group, then you can edit the gradient.  But the only
> way to edit the fill opacity of 0.75 is through the XML editor, because
> it's a property of the object iself, not of the gradient stops, and
> Inkscape doesn't provide convenient access to it.  (This, at least, is
> the case in Inkscape 0.39.  I haven't tried Inkscape 0.40 yet.)  It's
> probably easier to get rid of the bad fill opacities by hand-editing the
> file, as I suggested before.
> 
> 
>>So it's actually the previous versions that had it wrong, then?
> 
> 
> Yes, unless Batik and Adobe have got it wrong too.
> 

You all should forward these errors to the inkscape mailing list to see what is up.

Jon



-- 
Jon Phillips

USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)