Hey all.
I’m struggling to get a compound path to work in the GF app from Affinity Designer. I’m using the recommended export settings for SVG. Below I’ve included the object from AFfinty and what it’s looking like in the GF app. Ive basically subtracted a circle path from a rounded rect path, removed paths and gave it a fill. It always shows up as a filled-in rounded rect in GF. Any ideas?
1 Like
This is a known bug in the Glowforge software. The fix is to reverse one of the paths before doing the subtract operation. If there are a lot of paths then it’s a real pain to fix them all. Hopefully Glowforge fixes the bug soon. I reported it six months go and I’m still waiting for them to fix it. 
3 Likes
Thanks for the reference. It took a while, but I finally got my logo to work. That is a giant PITA.
GLOWFORGE SUPPORT: Kindly provide a timeline when this get addressed in the software.
So that you don’t sit around stewing about a lack of action on this… GF has stated they will not give timelines on fixes or features. They never have and probably never will. Even a day before a new release they give no information about what will change.
And never a full description of what has changed or a date when it changed.
If you want repeatability in results, then I would suggest that all engraves be converted to bitmaps prior. Do so at a sufficiently high resolution and there is no loss of quality.
Rendering vectors is difficult in and of itself, though un-filled vectors can be expected to be stable over time.
However, fill rules are notoriously finicky and it is clear that there will be bug fixes in the future. Even with bug fixes, it is quite likely that the fill rule used by your design package may be different than the GF (with no bug on either side) and, thus, rendering to bitmap will guarantee you always get what you want.
The fill rule is specified by an attribute in the SVG file, which an SVG reader is obliged to obey. The GFUI ignores it, which is a huge bug. If you look at the same file with a browser it will show it correctly.
4 Likes
No, they’re not. There are only two of them and they’re both well defined and have been used for many decades. Postscript contained both back in 1984: the “fill” command used the non-zero rule and the “eofill” command used the even-odd rule. (Likewise for the “clip” and “eoclip” commands for clipping paths… not that Glowforge supports clipping paths yet but don’t get me started on that.)
All SVG implementations are required to support both. The fact that the Glowforge doesn’t yet is a major bug.
3 Likes
Sorry-- what I meant was that rendering is notoriously finicky. Having implemented a number of renderers over the years, it is a right giant pain in the ass to get things pixel for pixel perfect. Doubly so when your renderer is sitting on top of a stack of software that is provided by other vendors, subject to change without notice (which probably isn’t as big of a deal for the actual cutting process in this case, but certainly is when doing browser targeted GUI).
As such, I still stand by the advice: Keep the original vector graphics around, of course, but create a high resolution render of whatever it is you want to repeatedly reproduce and engrave from that bitmap. It is less likely to change in result over time; still possible, of course, because the bitmap -> engrave algorithm is evolving, but it takes out one significant variable in the process.
Thanks for your help, @tim1724.
@avidflyer Thanks for asking about this. While I don’t have official timelines for fixes, you can see the newest features and fixes on our Latest Improvements page.
Thank you for the suggestions as well – I’ve shared them with the team.