search

lafriks / go-svg

Golang SVG file parser and rasterizer library
BSD 3-Clause "New" or "Revised" License
5 stars 2 forks source link

transform attribute with both translate and scale generates incorrect matrix #3

Closed pekim closed 1 month ago

pekim commented 1 month ago

I have been using this library to parse SVGs, and skia to render them. And I've run in to an issue with one of the SVGs that I happened to try.

https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/ie-lock.svg includes <g transform="scale(0.46) translate(22,56)"> that positions and sizes the 'e' in the lock. I had a problem when I rendered this using skia, the 'e' is scaled correctly but is not in the right position.

At first I though that maybe I was applying the matrix for the transform incorrectly in my use of skia. However I then hacked the gg and rasterx examples in this repo to render the ie-lock file, and they both exhibited the same the position issue. So it looks like the problem is possibly in the Matrix2D methods in this library.

This is how rasterx renders the svg. example

I don't have a good grasp of matrix maths, so I've not been able to determine exactly where the problem lies, or what the solution would be.

richardwilkes commented 1 month ago

Just by looking at the image, I'm guessing the scaling is being applied to the translation coordinates as well, probably due to the ordering in the transform. Out of curiosity, if you flip the order (e.g. <g transform="translate(22,56) scale(0.46)">) does that improve anything?

richardwilkes commented 1 month ago

Nevermind. I tried that out and it didn't make any difference.

richardwilkes commented 1 month ago

Hmm... it also displays incorrectly in vscode's svg preview, but fine in a browser.

richardwilkes commented 1 month ago

I've verified that if I adjust the svg by dividing the translate coordinates by the scale, that the "e" is placed correctly, so I suspect order of application is indeed the issue.