evil-mad / robopaint

The software for your friendly painting robot kit!
126 stars 34 forks source link

Oops! Looks like there are some errors in your SVG - error #139

Closed powtac closed 10 years ago

powtac commented 10 years ago

I can "Open SVG..." this SVG file: https://www.dropbox.com/s/t1kron63pasmoqc/ah7.svg but when I press print, Robopaint fails with an error message like:

Oops! Looks like there are some errors in your SVG

I created the SVG file using the StippleGen_2 application. I also was able to open the file in Inkscape and edit it, so it does not look like a broken SVG file. Is it too complex for Robopaint/Watercolorbot?

oskay commented 10 years ago

I think that it may be a matter of file complexity. I was able to open the file in Inkscape, select all and Path menu>Union to make it into a single object. After saving, RoboPaint was able to open it.

powtac commented 10 years ago

Good point, I think this should be added to the wiki description of how to use robopaint or add this solution to the error message telling this "solution"...

rogerfachini commented 10 years ago

I think I can add a little bit to the error message telling them to make sure the file is a single object (I think that means a single layered image). I'll make a new commit to this soon.

rogerfachini commented 10 years ago

Just looked at the code, and the full error message is: "Oops! Looks like there are some errors in your SVG that RoboPaint couldn't automatically fix. \n\n We suggest you open the SVG in Inkscape or another SVG editor, simplify the document or just resave it. \n\n You can continue and try to print this, but you may have issues. Error given below: \n\n\n" The second half of the message plus the error code is cut off in NW's message box. Working on fixing that now

techninja commented 10 years ago

The really important part about this is the actual error at the bottom: "Too much time spent in unload handler", which basically means, everything needed to be done to convert this file to be printed was just too much to finish in the time it had to switch between modes. There's 998 circles that all have to be converted to paths, so it was just happily working through it, but didn't have enough time to finish.

Printing these kinds of images is certainly not out of the question, but some work will have to be done to simplify what's being done to them. @oskay's suggestion is a perfectly workable solution for the time being, though I'd imagine we should probably work to improve the interface to not require long wait times without progress notification for long jobs. I'll create a feature issue for it an reference this issue for a paper trail.