Aspects of design do not appear in GFUI and do not print, what am i doing wrong?

I use Inkscape on MacOS. It’s doable. I like AD, but there are still some things that work better in Inkscape.

It’s a known issue; search on “winding rules” and you’ll see it’s come up often in the past. :stuck_out_tongue_winking_eye:

1 Like

yes i see that, just got finished reading a quite long thread on the subject. lots of troubleshooting but not to many solutions implemented in the GFUI yet i see.

what build of inkscape on macOS are you using? i found that xquartz was a nightmare of window focus problems. i used to have access to Illustrator but wanted to try to focus on Affinity since it was so much less money while being a macOS native application.

Looking at the blowup of the GFUI; It looks like you have two things on top of each other. If you just changed the color of one they would be two layers in the GFUI and you could ignore ir even deleat it there, or you could try and delete one in Affinity and undo if you get the wrong one.

I have 0.92. I mostly use Affinity, but when it comes to node editing stuff, I still prefer Inkscape.

1 Like

no that’s not what’s happening. its seems this is a fairly well documented bug (Bug: SVG fill-rule:evenodd not supported) that hasn’t been addressed as yet. this is a single curve object with holes in it that are being filled erroneously by the GFUI’s interpretation of the fill-mode type

in my design software those filled in areas are empty.

i’m going to resign myself to finding another work around (PDF, give inkscape another try on macOS, voodoo, ritual sacrifice) but would LOVE IT if GF fixed this aspect in the GFUI so that it interpreted the fill-mode properly.

Do you see that your design in AD is black on one side and blue on the other - while @geek2nurse’s fixed one is black on both sides - that would indicate that even AD understands there is a difference between the sides. That’s not a fix, but certainly a road worth researching

oh i can work around the issue, already have actually. its not about fixing my print anymore, its about fixing why GFUI isn’t rendering the original properly because it should.

My point is that it’s not the GFUI in this instance. Your program recognizes that there is a difference between the two sides, and the GFUI recognizes there is a difference

If your program was saying they were the same, and the GFUI was saying they were different it would be an issue with the GFUI

The bug is in the Glowforge interface. It absolutely needs to support both fill rules.

Affinity Designer uses the even-odd rule for the results of any Subtract operation. This is an entirely reasonable behavior as it makes implementing the operation easier and the SVG spec requires support for the rule. The Glowforge is non-compliant with the spec by not supporting it.

It does make it a real pain for AD users. The easiest workaround is to just rasterize shapes if they’re going to be engraved on the GF. (If they’re going to be scored or cut then the fill rule doesn’t matter.)

2 Likes

I DL’d your original and did not find extra parts but according to Inkscape neither the outline or fill was active which was weird though the part was “filled” to look at, and when I turned on the fill it went away and was replaced with the Inkscape fill which if turned off made the part invisible. Obviously there was some “third” thing not supported in Inkscape that might be confusing the GFUI.

1 Like

if a picture is worth 1000 words…

here’s video: https://www.youtube.com/watch?v=jcJg4KQbMaw&feature=youtu.be

i made another video to try to help drive home the issue for everyone. in this i make some simple shapes in AD, show the different rendering and then export an SVG and bring it into the GFUI.

and here’s both the original Affinity Designer file as well as the exported SVG.

fill-mode-test-files.zip (18.3 KB)

there! armed with my new knowledge of fill-modes i was able to take my design, select all, change to winding fill mode and then visually check for anything that filled wrong, i then pulled the improperly filling elements out into a scratch window, modified them using the reversing of nodes, re-subtracted them from their parent shapes and then checked the whole design once again by selecting all and re-applying the winding fill mode. and it looked good in AD. I then exported to SVG and threw it into the GFUI. and it looks like it is rendering properly now. this was a hassle. would be nice if i didn’t have to do that.

5 Likes

That sounds almost as complicated as activating the Stargate. Glad you at least have some kind of workflow now!

4 Likes

Is this how AD always looks? Why are the vertices so large?

i have them set to large so i can see them better. im doing most of this on retina displays and sometimes i need to see larger handles. i guess i’m getting old…

1 Like

No solutions implemented in the GFUI yet. They did announce a “fix” a year or so ago. But it wasn’t a fix in the sense that it would support the winding rule/even-odd fill but rather render it in the operation panel the way it was going to engrave. Up until then it would look correct (as you saw it in your design software) but would engrave filled instead. With the “fix” they now show that it’s going to engrave filled so you don’t waste the material finding out you’ve got a winding rule issue. So it’s better but it is not fixed yet.

5 Likes

I’m very sorry for the frustrating experience but I’m glad to hear that you’ve been able to resolve it.

I’m going to go ahead and close this thread but I wanted to let you know that I’ve also passed your report along to the team. If you have any additional questions, please don’t hesitate to open a new thread or email support@glowforge.com.