This fill-rule issue just bit me.
I’m using affinity designer and I have two concentric circles that should be filled between with a hollow space in the middle.
However, when I import it, Glowforge renders it as solid.
It was reported a couple of times including the link above, and those forum topics have been closed for months. Is this on a fix priority list?
Who knows, GF never disclose priorities or ETAs. But there are many very long standing bugs they have yet to fix. The rate at which they fix things is glacial.
^^^^ This.
For a lot of things it doesn’t bother me that they’re slow to make changes. Cosmetic issues in the GFUI, for example. I can even somewhat understand things like the lack of support for clipping paths, because that’s at least a somewhat difficult thing to implement. (Although if they used any off-the-shelf library it should already work.) But this is (a) a serious bug that causes a great many files not to print properly and (b) something that should be trivial to fix.
Illustrator may default to the non-zero rule and may even convert all paths to use it on export (I don’t know; I haven’t had access to Illustrator for years so I can’t check.) but most other drawing packages (Affinity Designer, CorelDraw, etc.) make heavy use of both fill rules. Even Adobe Photoshop defaults to using the even-odd fill rule, so it’s not even as if people who live entirely in the Adobe universe can avoid it.
You mean like a donut?
Yes, like that. Although your example file has the paths in alternate directions, so it works regardless of fill rule used. If both circles are drawn in the same direction then the even-odd and non-zero rules produce different results. (Except on Glowforge, where they will both be interpreted using the non-zero rule.)
Try this donut instead:
If you try to engrave it on a Glowforge you get this
I don’t really understand the programming side. I had assumed the issue was that people arent making it compound/combined/complex/whatever the term that software uses. What @tim posted in the GFUI is exactly what I would expect from two filled, un-compounded circles. Or one filled circle, really, assuming the larger circle is the filled one.
Is that whats happening?
My SVG loads correctly into the GFUI, cutting the inner and outer circle to make a donut shape.
The outer circle has a white fill (so no engrave). The inner circle has no fill. The inner circle was punched out from the outer circle in Illustrator, using the “minus front” command so it is a compound shape.
Illustrator is doing two things here. (a) It uses the non-zero fill rule (which GF supports) not the even-odd rule (which GF doesn’t) and (b) it is reversing the direction of one of the circles. (It has to do this in order to get a donut using the non-zero rule; if both paths have the same direction then the non-zero rule fills in the center.)
My example uses the even-odd rule and has the two paths in the same direction. As you can see in your web browser it should produce the same result: a donut. (If your web browser does not display a blue donut then you need to upgrade your browser.)
But because the GF doesn’t understand the even-odd rule it (incorrectly!) applies the non-zero rule instead. Thus producing the filled-in center.
Take a look at my blue donut. You agree that it is a blue donut with a hole in the center, right? It is a proper compound object. (No, it’s not a white circle sitting on top of a blue circle.) It just uses a different fill rule from the one Illustrator uses by default. Illustrator defaults to the non-zero rule. Some other software defaults to the even-odd rule.
If your browser doesn’t show a blue donut then your browser is broken and you should upgrade.
Try dragging my blue donut into the Glowforge UI and try to engrave it. The center will be filled in. Your browser is correct in showing a blue donut. The Glowforge is wrong in engraving it as a filled circle.
Also, please note that some versions of Illustrator have a bug where it ignores the fill rule when importing SVG. (Yes, the same exact bug as Glowforge.)
What’s happening is that the Glowforge is not applying the even-odd rule and is instead using the non-zero rule. This produces the incorrect result: a filled-in center.
An explanation of fill rules: Understanding the SVG fill-rule Property — SitePoint
I’ve come across this issue several times myself. My manual fix for it consists of changing the fill rule to nonzero (to see what Glowforge will see), either by text editor or using the XML node editor in Inkscape; breaking apart the compound path to be able to get to the individual elements; reversing the direction of the outermost path only in order to get the count correct (node tool, select subpath, type “R”); then recombining the subpaths back into one path. That is assuming that all the subpaths all wind in the same direction, which may not be the case.
Enabling Edit / Preferences / Tools / Node / Show path direction on outlines makes debugging these issues much easier.
It’s a major pain to fix each and every file. GF really needs to fix it on their end.
I have learned that Affinity Designer has the ability to show a shape with different fill modes. If you select your donut and then do Layer…Fill Mode… you can select Alternate (even-odd) or Winding (nonzero). Unfortunately, this only allows you to see what Glowforge is going to do to it; it doesn’t give you the mechanism to fix it.
If you create a circle in AD and then create another one inside it, select both, and hit Subtract, then set FillMode to winding, you don’t get a donut, you get a filled circle.
BUT…if you create a circle, create the other one inside it, then flip that inner circle horizontally BEFORE you subtract, you get a donut.
So this is a somewhat painful workaround for now. You have to remember to do it before you subtract.
I would love it if anyone has a trick for reversing the winding order of a closed curve. I haven’t been able to figure one out.
The Node tool has a “Reverse Curves” button:
Note that on a compound curve it will reverse the whole thing, even if you’ve used the Node tool to select only part of it. So if you are trying to fix a compound curve you need to Divide it first, reverse individual curves, then re-combine them.
So, what do you get when you use this Illustrator created file?
That one should work fine no matter what fill rule is used because the two circles are in opposite directions. So they produce the same result with both fill rules.
The problem is when you have the two circles going in the same direction. Then with non-zero you get the center filled in. (Whereas even-odd still produces a donut.)
It’s fixable (by reversing the direction of one of the paths) but fixing it wouldn’t be necessary if the Glowforge UI supported the even-odd fill rule. And while fixing a donut is trivial, fixing a compound path made of a few dozen objects is incredibly tedious. And again, pointless because Glowforge should fix this stupid bug.
It works like this:
For the odd-even fill rule, you draw a line across the shape and count intersections and fill while the counter is odd. So the hole will be even and therefore not filled.
For the nonzero fill rule, you look at the direction of the line you’re crossing. If the line is going right-to-left, you add 1. If it’s going left-to-right, you subtract one. And you fill whenever the total is not zero.
If both lines are going in the same direction, then the center total is either 2 or -2 and is thus filled. If the lines go in the opposite direction, the center is 0.
(I once wrote typesetting software and had to write the fill code for the type renderer.)
Yep. This.
Or with illustrations (because illustrations make it easier to understand) see the link I posted earlier:
The important takeaway is this: with the even-odd rule the direction of the paths doesn’t matter. With the non-zero rule it does.
Illustrator does a lot of magic automatically flipping your paths so that you can get what you expect even while using the non-zero rule. Most other software leaves it up to you to manually flip paths if needed. That’s a real pain, so most non-Illustrator software (including other Adobe programs, such as Photoshop!) uses the even-odd rule by default.
The non-zero rule is more generic and can handle shapes that even-odd can’t, but it’s a lot more fiddly.
Guess it doesn’t impact me since I use Illustrator… I just created a bunch of compound paths using even-odd fill-rule (which is an option in Illustrator) and couldn’t replicate a single issue in the UI.
Yes, like I said, Illustrator does a ton of extra work to try to keep you from shooting yourself in the foot. Programs that don’t cost an arm and a leg leave it up to the user. (But they usually use the even-odd rule which ends up making things work out. Because it’s easier.)
Illustrator ought to let you make a non-working example, but it might make you jump through some hoops to do so. I don’t know; it’s been years since I last used it.
In any other program it’s trivial to make a file that the GF chokes on. Many of us do it by accident all the time.
Here’s a quick example I made in AD (but you could do it in Inkscape just as easily and it should be easy in CorelDraw too).
As you can see, with the even-odd fill rule it doesn’t matter whether paths are clockwise or counterclockwise. But with the non-zero rule it makes a huge difference. So when people using programs other than illustrator make a shape using even-odd fill rule (and with Affinity Designer the Subtract operation always generates a shape using even-odd fill!) it matters a lot that the Glowforge treats it as if it used the non-zero rule! It means whatever is in the right column ends up looking like the left column on the Glowforge. Not a problem if you happen to have paths with alternating directions (bottom row) but a big problem indeed if the paths go the same direction (top row)!
And here you can see how the Glowforge mangles it:
Only the top-left shape should be solid. The other three should all have holes. But because Glowforge can’t handle the even-odd fill rule, the top-right shape is not rendered correctly.
