Here is the code again in text:
src <- rectGrob(2/3, 1/3, width=.6, height=.6, gp=gpar(lwd = 5,
fill=rgb(0, 0, 0.9, 0.4)))
dst <- rectGrob(1/3, 2/3, width=.6, height=.6, gp=gpar(lwd = 5,
fill=rgb(0.7, 0, 0, 0.8)))
svg("cairo.in.svg", width = 5, height = 5)
grid.group(src, "in", dst)
dev.off()
On 27/9/22 04:44, Paul Murrell wrote:
Could you also please send me the SVG code that your device is
generating for your example. Thanks!
Paul
On 27/09/22 08:50, Paul Murrell wrote:
Hi
Thanks for the report. It certainly sounds like I have done
something stupid :) For my debugging and testing could you please
share the R code from your tests ? Thanks!
Paul
On 26/09/22 10:27, Panagiotis Skintzos wrote:
Hello,
I'm trying to update ggiraph package in graphic engine v15
(currently we support up to v14).
I've implemented the group operators and when I compare the outputs
of ggiraph::dsvg with the outputs of svg/png, I noticed some weird
results.
Specifically, some operators in cairo (in, out, dest.in, dest.atop)
give strange output, when any source element in the group has a
stroke color defined.
I attach three example images, where two stroked rectangles are used
as source (right) and destination (left).
cairo.over.png shows the result of the over operator in cairo
cairo.in.png shows the result of the in operator in cairo
dsvg.in.png shows the result of the in operator in dsvg
You can see the difference between cairo.in.png and dsvg.in.png. I
found out why I get different results:
In dsvg implementation there is one drawing operation: Draw the
source element, as whole (fill and stroke) over the destination
element (using feComposite filter)
In cairo implementation though there are two operations: Apply the
fill on source and draw over the destination and then apply the
stroke and draw over the result of the previous operation.
I'm not sure if this is intentional or not. Shouldn't the source
element being drawn first as whole (fill and stroke with over
operator) and then apply the group operator and draw it over the
destination? It would seem more logical that way.
Thanks,
Panagiotis
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel