Re: [Rd] Question about grid.group compositing operators in cairo
lt "over" operator] and then combined with the other
rectangle using the "in" operator) ...
grid.newpage()
grid.group(groupGrob(srcRect), "in", dstRect)
<11>
A possible change would be to force an implicit group (with op=OVER)
on the 'src' and 'dst' in dev->group(). I believe this is effectively
what you are doing with your dsvg() device (?).
Currently, dev->group() does this ...
[OVER] shape shape shape OP shape shape shape
... and an implicit group on 'src' and 'dst' would do this ...
([OVER] shape shape shape) OP ([OVER] shape shape shape)
An implicit (OVER) group would make it easier to combine multiple
shapes with OVER (though only slightly) ...
grid.group(src, OP, dst)
... instead of ...
grid.group(groupGrob(src), OP, dst)
On the other hand, an implicit (OVER) group would make it harder to
combine multiple shapes with an operator other than OVER (by quite a
lot?) ...
grid.group(groupGrob(shape, OP, groupGrob(shape, OP, shape)), OP, dst)
... instead of ...
grid.group(src, OP, dst)
The complicating factor is that what constitutes more than one shape
(or drawing operation) can be unexpected ...
gList(rectGrob(), rectGrob()) ## obvious
rectGrob(width=1:2/2) ## less obvious
rectGrob(gp=gpar(col=, fill=)) ## a bit of a surprise
<12>
In summary, while there is some temptation to add an implicit group
around 'src' and 'dst' in a group, there are also reasons not to.
Happy to hear further arguments on this.
Paul
On 28/09/2022 8:04 am, Panagiotis Skintzos wrote:
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
<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about grid.group compositing operators in cairo
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
Re: [Rd] Question about grid.group compositing operators in cairo
Hi, sure I attach the test code and my svg. You can also find my current work on ggiraph in the branch ge15 on github: https://github.com/sigmapi/ggiraph/tree/ge15 Thanks, Panagiotis 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
[Rd] Question about grid.group compositing operators in cairo
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
