[Clipart] transparent turkeys

[Stephen Silver]

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.

-- 
Stephen Silver