You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a small SVG reproduction of an issue I've seen where feOffset is used to create a drop shadow, but it turns out to be inconsistent when rotated - the global transform doesn't seem to be applied to the offset, so the positioning of the offset image is wrong.
I've done the above with a couple of different values of rotate(N), across a couple of different renderers. Image were rendered to 400px, and scaled down to 200px square in the table markdown below:
rotation
resvg
Gimp (rsvg)
Chrome
0
20
45
Seemingly rotating each item independently then applying the offset
The offset seems correctly modified, but centre of rotation isn't
I assume this is correct - and that it is rotated around the centre of the image?
There's probably a second bug/inconsistency relating to the centre of rotation. I think all of the above are identical if transformed with rotate(N 0 0), so have different ideas of what 0,0 is.
I haven't quite worked out which bit of code should be handling such adjustments - assuming it's part of is it something that should be done by convert_offset, or does this relate to the TODO: Wrong! Does not account rotate and skew in resolve_primitive_region?
The text was updated successfully, but these errors were encountered:
I have no idea how to implement them. Would probably require lots of significant changes to how filters are rendered.
It's a very old issue: #254
And do you have an idea of which rotation origin is correct?
Filters with transform is effectively undocumented in SVG, so I have absolutely no idea either. But in general we always follow Chrome, since it has the best SVG support in general.
I've got a small SVG reproduction of an issue I've seen where
feOffset
is used to create a drop shadow, but it turns out to be inconsistent when rotated - the global transform doesn't seem to be applied to the offset, so the positioning of the offset image is wrong.I've done the above with a couple of different values of
rotate(N)
, across a couple of different renderers. Image were rendered to 400px, and scaled down to 200px square in the table markdown below:There's probably a second bug/inconsistency relating to the centre of rotation. I think all of the above are identical if transformed with
rotate(N 0 0)
, so have different ideas of what0,0
is.I haven't quite worked out which bit of code should be handling such adjustments - assuming it's part of is it something that should be done by
convert_offset
, or does this relate to theTODO: Wrong! Does not account rotate and skew
inresolve_primitive_region
?The text was updated successfully, but these errors were encountered: