The center of the A and the section of the A’s right arm that is next to the center have all been engraved out to about half the depth of everything else. This was on proofgrade maple.
Interestingly, after you click “print”, the preview shows a filled-in “A”.
Yeah looks like it thought both shapes were filled. I haven’t had a chance to look at your file but if I did my first thought would be that your A is 2 paths, where the void is actually a white filled triangle on a solid A border.
To verify: (apologies if you’ve already done this, or if I’m wrong. Again, no access to the file)
Select the entire A by drawing a rectangle selection around it.
Look at the bottom of the screen to see what type of thing you’ve selected.
If it says it’s a group, break it up with control-shift-G
My guess is that it’ll say you have two objects of type path.
Select both and then select path->exclusion.
You should now have a single object of type path, with a true void.
(PS: Btw my whole idea is a long shot because the text to path process you mentioned doesn’t usually cause this problem, but if you post processed it at all by breaking paths apart or if Inkscape is having a weird day you might have gotten here. But yeah even a white filled vector will engrave.)
Now that’s really interesting. I am 99% sure there’s nothing wrong with this file. It’s not an invisible fill inside the A, and it’s not using an even-odd winding rule, which are the two obvious suspects. I even took it into Illustrator and exported a simplified version with no styles applied and it does the same thing. I think this is a legitimate bug in Glowforge’s vector-to-raster engine.
Personally, I’m suspicious of using “engrave” on vector art, I prefer to just pre-rasterize it myself, and this example reinforces my superstition.
When I select it, it says “Group of 1 object in root”. If I ungroup it (twice), turns into “Path 17 nodes in root.” If you open up the SVG, it’s a “path” inside a “g#text817” inside a “g#layer1”. (I think Inkscape always groups all the individual letters into a “group” by default, when you break a word up into paths, which is where the “text817” group came from, but at the bottom it’s just a single path.)
If the entire thing were filled in, I’d expect it to engrave the center out to the same depth as the rest of the A, but it isn’t. What actually comes out looks like it’s trying to engrave this:
With the red bit at half-ish the power of the black bit.
Removing that extra line and recreating the path “fixes” the “problem”. I guess the extra line is causing it to get confused about what’s inside and outside. Problem in quotes, because I don’t think it’s entirely fair to blame the file, as the Glowforge backend seems to be rasterizing this completely different from everything else – including its own web UI! As much as I’m tempted to dig deep into the SVG spec and quote chapter and verse, I need to get to work. :-/
You know, good point. I’ve only ever had really janky engrave performance with vectors. I tend to rasterize now too unless I create the shapes myself. Any premade or imported vectors are just too likely to have issues.
I will sometimes redraw exported svgs from sketchup, for example. They do something funky with the part that I can’t figure out. It’s easier to just use bezier to draw over it and trash the original.
Maps from wiki have some invisible clones in there too. I find I have to decline then, copy the uncloned path and paste it into a fresh svg. Then I rasterize and go forward. Svgs are the Wild West.
I believe the web UI depends on your browser to do the SVG rendering, at least in places. At least that’s what it looked like when I was investigating the fill rule bug.
Yes it uses your browser to show it on the screen, and that of course gets it right but then it has its own interpretation when it sends it to the machine, which is nothing like browser representation at all. For example it closes open paths and ignores stroke width, etc.
It’s not uncommon for free fonts to be poorly constructed. They are usually being designed for looks, without regard to other considerations.
We need to be careful to check converted fonts for errors like superfluous lines, stray points, self-intersecting paths, etc., especially with fonts that are particularly exotic or distressed, or auto-traced versions of commercial fonts.
I took that free downloaded font into fontographer re-exported cross platform, but did not re-make it. I had no Idea the indivdual letters were soooo buggy. Looks like it was scanned and outlined and only some of the letters were optimized. There are far to many points in some of the letters and it’s causing errors when GF is trying to read the vectors.
I didn’t have any problems with the A’s but did have a shift on the letter D so I fixed and replaced in the downloads. I will re-make the problem letters when I get a chance. In the meantime use with caution, look really carefully at the cut lines in the GF, they are showing up bad in the cut program but not in Illustrator… and apparently not with the A so double lines and double points not showing up but bad tangents are.
That extra line is an unclosed path. When converting to raster, the GF software (and this is something of long standing) helpfully closes unclosed paths by magically making a connection between two nodes of the unclosed path. Nothing good has ever been known to come of this helpful action. (I suppose if you had a barely-unclosed polygon it might help?)
In inkscape, I think you can solve this in one shot by selecting the letters and then selecting path->union.
I think it works because union in inkscape completely redraws the vector in question (good and bad, sometimes it takes small liberties if your path is really jacked up [see @paulw’s reply above about open paths] , caveat emptor). I tried this on the sample file earlier in the thread, and it looks like it healed it in one simple action. I can’t say for sure if this method would work the same way in illustrator (not an AI guy… I think it’s the “pathfinder->unite” command?), but it sure looks like it worked in Inkscape.
