search

srwiley / rasterx

Rasterx is an SVG 2.0 path compliant rasterizer that can use either scany, the golang vector or a derivative of the freetype anti-aliaser.
BSD 3-Clause "New" or "Revised" License
133 stars 11 forks source link

support UserSpaceOnUse and objMatrix transform of its points according to object's current transform #3

Closed rcoreilly closed 6 years ago

rcoreilly commented 6 years ago

tested that that this still reproduces same results on the test data and it also works for my test cases of the UserSpaceOnUse version. For oksvg to support this, it would need to be able to read in points as either %'s or raw numbers, and not force them to max out at 1. It also needs to pass in the object transform.

rcoreilly commented 6 years ago

I just added a further commit that now allows all my test cases to work. I've switched over my code to using my forks so it works without the pull request, so you can test it out there to see what I'm seeing.. If you build the latest github.go/goki/gi/examples/svg and open the fig_srn_time_predict.svg or fig_cortical_layers_in_hid_out.svg svg files, you'll see that they render the gradients in the right place -- the former looks just like inkscape or boxysvg, while the latter uses radial gradients and there appear to be some issues, but the transforms look correct. Furthermore, I'm pretty sure this code is now compatible with the text in the spec: https://www.w3.org/TR/SVG/pservers.html#LinearGradients

These changes produce very different output on your test cases in oksvg and rasterx, so clearly there is some additional work needed to reconcile your version of how these things are supposed to work with what appears to work for me and these test cases. None of these test cases combine a Bounding Box version plus the transform, but the spec above seems pretty clear about how it should work, as coded.

At some point I'll continue working on the radial gradients to get it to match the rendering from inkscape, so that will result in another commit here, but it probably won't be for another week or two.

At this point, it looks like the overall svg parsing and rendering in GoGi is working for many of my svg files, mostly generated from inkscape, used in my scientific work.

srwiley commented 6 years ago

Hey Randall,

I'm not trying to ignore you, just been a bit busy lately. Can you give me a higher lever view of what the issue is for the gradients? If your changes do not mess up my simpler examples I am fine with them. But I would appreciate a glimpse from the thousand foot level.

Thanks, Steve

On Sun, Jul 22, 2018 at 3:02 PM, rcoreilly notifications@github.com wrote:

I just added a further commit that now allows all my test cases to work. I've switched over my code to using my forks so it works without the pull request, so you can test it out there to see what I'm seeing.. If you build the latest github.go/goki/gi/examples/svg and open the fig_srn_time_predict.svg or fig_cortical_layers_in_hid_out.svg svg files, you'll see that they render the gradients in the right place -- the former looks just like inkscape or boxysvg, while the latter uses radial gradients and there appear to be some issues, but the transforms look correct. Furthermore, I'm pretty sure this code is now compatible with the text in the spec: https://www.w3.org/TR/SVG/pservers.html#LinearGradients

These changes produce very different output on your test cases in oksvg and rasterx, so clearly there is some additional work needed to reconcile your version of how these things are supposed to work with what appears to work for me and these test cases. None of these test cases combine a Bounding Box version plus the transform, but the spec above seems pretty clear about how it should work, as coded.

At some point I'll continue working on the radial gradients to get it to match the rendering from inkscape, so that will result in another commit here, but it probably won't be for another week or two.

At this point, it looks like the overall svg parsing and rendering in GoGi is working for many of my svg files, mostly generated from inkscape, used in my scientific work.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/srwiley/rasterx/pull/3#issuecomment-406900525, or mute the thread https://github.com/notifications/unsubscribe-auth/ALlXB48C5gEfE4foxrc0thLcgxgLgfBQks5uJPZhgaJpZM4VZPMh .

rcoreilly commented 6 years ago

Steve -- I finally sorted it all out with that last commit. The issue is the GradientUnits parameter for gradients. Your original code was correct (according to Inkscape at least) for the ObjectBoundingBox case, but my new changes are necessary to support the UserSpaceOnUse case. The gradient's Matrix transform operates in two very different ways for those two different cases.

So, now, your original test cases work as before, so there is no additional reconciliation necessary.

srwiley commented 6 years ago

OK, that is really cool Randy. Testing is paramount. I will get around to checking it in soon. But you know... it is summer in NW and I am on vacation...

On Sun, Jul 29, 2018 at 1:44 AM, rcoreilly notifications@github.com wrote:

Steve -- I finally sorted it all out with that last commit. The issue is the GradientUnits parameter for gradients. Your original code was correct (according to Inkscape at least) for the ObjectBoundingBox case, but my new changes are necessary to support the UserSpaceOnUse case. The gradient's Matrix transform operates in two very different ways for those two different cases.

So, now, your original test cases work as before, so there is no additional reconciliation necessary.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/srwiley/rasterx/pull/3#issuecomment-408661583, or mute the thread https://github.com/notifications/unsubscribe-auth/ALlXB55Qa2oidJQ-cNA7mCJNnCFMCMCQks5uLXXlgaJpZM4VZPMh .