SVG transparency renders a strange border/halo

Hi there!

I was building a fritzing part adapting an SVG export from a KiCad PCB so I could draw a perfect-clean illustration with the typical layers: substrate(FR4), copper, soldermask and silkscreen. The idea was to create a process/tool to do this semi-automatically and “easily” export my KiCad designs directly into fritzing illustrations.

I was almost there when I hit this wall: the soldermask SVG layer is 65% opaque, so it allows to perceive the copper vs substrate difference, and it was perfect… in Inkscape :disappointed_relieved: but in Fritzing, the border gets somehow rendered:


fritzing rendering a halo

this in Inkscape

It’s strange how that halo gets rendered, because it has an unexpected inset:man_shrugging:

I already found a workaround consisting in converting the border (stroke) into a shape (path), but it is a problem that I would like to avoid because it requires manually intervention. I tried many many many things, but didn’t find a better solution to be able to not remove the border/stroke.

I post the case here in case anyone hits this same issue, looking for ideas or comments and, maybe, elevating this into a bug/issue if it finally is one.

regards!

transparency.fzpz (8.3 KB)

Fritzing is created to use SVG Tiny (plus some). According to SVG Tiny, Rendering Model, 3.4.1 Rendering shapes and text Fritzing is rendering that svg content correctly.

Shapes and text can be filled (i.e., paint can be applied to the interior of the shape) and stroked (i.e., painted applied along the outline of the shape). A stroke operation is centered on the outline of the object; thus, in effect, half of the paint falls on the interior of the shape and half of the paint falls outside of the shape.

The fill is painted first, then the stroke.

Each fill and stroke operation has its own opacity settings; thus, you can fill and/or stroke a shape with a semi-transparently drawn solid color, with different opacity values for the fill and stroke operations.

The fill and stroke operations are entirely independent rendering operations; thus, if you both fill and stroke a shape, half of the stroke will be painted on top of part of the fill.

Not a bug. Inkscape rendering (and my local viewer programs) are not using the SVG Tiny profile, hence the difference.

Simply removing the stroke from that image is not sufficient to get Fritzing to render like you expect. Removing the stroke (setting it to “none”) will “inset” all of the edges by half of the current stroke width. Effectively moving the edge of the rendered content to the edge of the halo. Inner edge for the cutouts, outer edge for the outer edge of main path. To get an accurate rendering of what you want following SVG Tiny rules requires setting stroke=“none” and adjusting all of the path edges by half of the stroke width.

thanks for the clarification and the link to the docs @microMerlin: it sheds some light. Once more, different rendering models from Inkscape and fritzing (embebed svg library). It isn’t ideal, but at least I know what to expect.

regards!