Well I suppose they’re never going to fix it if people don’t keep complaining about it, so here goes:
Dear Glowforge, please fix this 2+ year old bug that is really hampering my migration away from Illustrator:
Sincerely,
Me
2 Likes
A simple answer has been there from the first 
In the GFUI any vector is able to be a Cut, an Engrave, or a score.
Where it is possible to get tricky is when the vector has an opening that may show up differently between different programs. The GFUI will only properly fill if the inner and outer vectors are the same object. This is also the plan and been the same since the beginning.
To separate vectors into different layers, they only need to be different colors. How thick or thin, the outline, filled or not does not matter, only the colors being different (or exactly the same as the hex value is what matters).
1 Like
I’m not sure I follow. For example, this donut below. The inner and outer circles are the same vector object, but are both in the same direction. While the SVG specifies the even-odd fill rule, GF is applying the nonzero rule instead, which results in a donut with a “filled in” hole in the GUI. Discussed at length in the first linked thread above. As others have mentioned, you can get around the issue with either manual SVG TXT editing or various manipulations to the winding order in the design software, but ideally GF would just interpret the SVG to give the correct results.
2 Likes
It does. But only for basic Svg stuff. If there is complex feedback capability (text is a good example that you can change on the fly) the GFUI reads only basic vectors and needs to receive that. It is up to the 3rd party program to provide that. Inkscape operates on a pretty basic level but things like text or image clipping, or fancy fills that it does will not translate, and must be broken into straight vectors or images, which takes a lot less effort than my writing about it,
Not sure what program was used to create that donut shape but if you create it in inkscape using the exclusion function there is no issue at all. Once I learned those basics I have never had an issue
1 Like
The design program generates the shape correctly - the UI/app doesn’t render it correctly per the SVG specification. The biggest ingress they’ve made towards resolving it is at least rendering it in the app so that you know that it’s not right (versus before, it would render it as expected/designed, but perform the job incorrectly, IIRC).
2 Likes
Glowforge claims to support SVG.
Supporting both fill rules (non-zero and even-odd) is a required part of that specification. Both fill rules have been a standard part of all important computer graphics systems for the last 35 years. Both fill rules are used by nearly all major drawing applications. Both fill rules have been supported in every web browser implementation of SVG ever.
This is a major bug in Glowforge’s SVG support. It’s absolutely incredible to me that they haven’t made any effort to fix it in the 3+ years since it was reported to them.
2 Likes
You recall correctly. They declared it fixed when they made the correction to display it as incorrectly interpreted by the GFUI vs leaving it displaying as designed but not as the GFUI understood it. As you noted, at least now we know before we do the engrave that it’s going to be wrong so can fix the file. Before you could waste the material and a fair amount of time before you found the file had the issue.
2 Likes
Yes, please fix it or at least admit fixing it is not on the table and you only support some svgs. It’s a huge PIA and way more time-consuming than it should be, and that’s for those of us who are aware of the bug. Imagine how many users out there don’t have a clue and how frustrating it must be for them when it happens. And yes, seeing it in preview is better than nothing, but it’s not a fix and if you have a really complicated design, it can still be hard to catch during preview. And if was a matter of a known rule or circumstance when it will happen, then it would be easier to design around. But it’s not and I never know when it’s going to pop up or not.
Here’s an example. I had about 20 variations of these design and I got two or three different fill rule issues on some of the designs, but not all. (Only showing one errorexample here.) There may have been a pattern to it, but figuring it out is above my pay grade and I shouldn’t have to keep uploading little design tests along the way to make sure the GUI will get it right or not. And I shouldn’t have to spend 30 minutes working around it or fixing it either.
3 Likes
I don’t believe so.
They support the file format, but not all the functions. Stroke style modifiers on paths, for example, are ignored (width, dash, etc.)
Understood. However, we’re only talking about recognizing two paths. It doesn’t get much more basic than rendering two circles correctly. Except maybe rendering one circle!
Doesn’t hurt to bring it up again.
Just guessing it’s such a low priority they have little motivation to invest effort to change it. It’s come up a handful of times with over 30,000 users now.
Then they don’t “support” the file format. They support some of the file format. They don’t support the file format that contains functions they can’t handle in the GF software.
I agree it seems to be a low priority for them though. They’ve appeared to ignore it since they “fixed it” by updating the UI to show how it will render in the GFUI. Just another issue in the hopper.
1 Like
The “workaround” involved is so simple and direct it needs no special attention unlike say the need for the outline tool that most of the Noun Project stuff that would be useless without that part.
Sorry, but that’s just incorrect. I think you’re misunderstanding the problem, which is causing confusion. This has nothing to do with cut vs score – this is what happens on fill, and whether the glowforge properly renders SVGs with intersecting filled areas.
If you’re curious, please read the links in the first post.
1 Like
Here’s a good explanation of fill rules in SVG, with examples:
The nonzero and evenodd rules have both existed for decades and just about every graphics library on the planet supports both. Both fill rules are included in all the common vector formats, including Postscript, PDF, and SVG.
Some graphics libraries add support for additional rules, such as positive and negative, which use winding numbers like nonzero but they care about the sign of the result rather than just looking at whether it’s non-zero. But those fill rules are not commonly used and I don’t think any of the general-purpose vector formats support them. (Such rules are mostly encountered in niche uses, such as rendering maps on a sphere where it’s not possible to choose an infinitely far away “outside” point.)
1 Like
Thank you so much for all the feedback. We really appreciate it.
I’ll make sure the team sees it.