Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The rendered svg path always closed, impossible render the curve line (it will curve ring). #63

Open
3dformortals opened this issue Oct 4, 2017 · 11 comments

Comments

@3dformortals
Copy link

3dformortals commented Oct 4, 2017

Tested targeting ... html5 debug, windows cpp debug.
Look like the path "z" parameter always ignoring.
original svg
originalsvg
rendered svg
renderedsvg

svg file code<?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" width="800" height="200" viewBox="0 0 800 200" version="1.1" id="svg8"> <defs id="defs2" /> <metadata id="metadata5"> <rdf:RDF> <cc:Work rdf:about=""> <dc:format>image/svg+xml</dc:format> <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> <dc:title></dc:title> </cc:Work> </rdf:RDF> </metadata> <path id="path4485" d="m 30,80 c 0,0 -8,-49 20,-52 28,-2 33,53 33,53 z" style="opacity:1;fill:#f7ff2f;fill-opacity:1;stroke:#ffadfe;stroke-width:5;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> <path id="path10" d="m 13,13 q 50,60 30,0 " style="opacity:1;fill:none;fill-opacity:1;stroke:#ff0000;stroke-width:5;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> </svg>

<path id="path4485" d="m 30,80 c 0,0 -8,-49 20,-52 28,-2 33,53 33,53 z"... must be closed

<path id="path10" d="m 13,13 q 50,60 30,0 "... must be not closed

@jgranick
Copy link
Member

jgranick commented Oct 4, 2017

Could you also test the Flash target? That will help us know whether it is an SVG parsing issue, or an issue in the OpenFL vector renderer. Thank you 😄

@3dformortals
Copy link
Author

3dformortals commented Oct 5, 2017

flash (swf) work good. cpp still closed. i try to read and understand the library source, but not enought strong for this :|
0

@3dformortals
Copy link
Author

this look like start point of broken logic
https://github.com/openfl/svg/blob/master/format/svg/PathParser.hx#L36-L37
the svg Z and z no need to be adsolute and relative(as usual svg path syntax) this is closing command, have no coordinates

@3dformortals
Copy link
Author

3dformortals commented Oct 14, 2017

may be it help you found the bug more faster ;)
https://github.com/openfl/svg/blob/master/format/svg/SVGData.hx#L691
var d = inPath.exists ("points") ? ("M" + inPath.get ("points") + "z") : inPath.exists ("x1") ? ("M" + inPath.get ("x1") + "," + inPath.get ("y1") + " " + inPath.get ("x2") + "," + inPath.get ("y2") + "z") : inPath.get ("d");
if i right understand then this syntax add "z" in all case(except cases the element is ellipse or rectangle ) at the end of data... and this is look like bug, because the element started from "M" can be not closed(have no "z") , can have "x1" parameter and can be not ellipse and not rectangle in same time. But "z" will be added in case above. This is wrong.

@jgranick
Copy link
Member

jgranick commented Oct 16, 2017

I just tried this locally, and it is working properly on HTML5 and desktop:

screenshot from 2017-10-16 15-25-12

What version of OpenFL are you using?

@3dformortals
Copy link
Author

3dformortals commented Oct 17, 2017

What version of OpenFL are you using?

openfl 3.6.1
lime 2.9.1
i use haxeflixel... other versions still can't work properly
when you say " desktop " you mean neko?... i test with cpp windows

new details... i test again all platform and have this result now:
use vscode 1.17.1 , win7 64
-flash ... done (right unclose rendering curve)
-lime build android ... done
-lime build neko ... done
-lime build cpp ... done
-lime build cpp -Ddebug -Dnext ... fail (was my default target settings for vscode at first testing above)
-lime build html5 ... fail
-lime build html5 -Ddebug ... fail

@jgranick
Copy link
Member

Hmm, this must be something that was fixed in a later version, testing OpenFL 6 and Lime 5, the SVG renders properly

@3dformortals
Copy link
Author

autchhh, this sounds worst then bug, because look like the openfl will not be upgraded... always :). I only hear sometimes something about the work in process but the result , as always null, we still have no new openfl version using way for haxeflixel. Openfl 3.6.1 is immortal lord of haxeflixel country.

@jgranick
Copy link
Member

I have a fork that mostly works:

https://github.com/jgranick/flixel

The MODE demo worked properly with this fork, though occasionally an enemy jet would disappear, I'm not sure why. With a little help, it might be possible to fix that

@3dformortals
Copy link
Author

With a little help, it might be possible to fix that

fix what? demo or flixel... english not my native
If this not hard for you, and need, can i try to help etc. Little piece. If i can't(because it hard to me) i just will understand it and will sure, and you too can be sure it not for my level. But i think this is level close pro, but not my level.

@jgranick
Copy link
Member

Flixel was working almost correctly. The issue where sometimes the enemy ship was disappearing is something based inside of Flixel itself... something my code didn't fully resolve. I was hoping someone using Flixel might know why it was happening

Without fixing that minor bug, it's possible that my fork of Flixel will still work properly for many projects, so it might be worth trying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants