Just an FYI really, I don’t expect anything to be done about this.
The “Clip” feature in inkscape is not supported by GF.
Neither is the use of stacked objects and/or layers to prevent the cutting of lower layers.
It seems an obscure issue and in a way it is, but clipping lets you effectively crop objects
Really? I was just doing some initial Inkscape tutorials and tried out a clip on some art and it 'Forged fine. I’m a rank beginner so I’m likely unaware of all it can do yet. Can you expand on how it’s not supported? Like, what should it do and what does it send up doing?
Thanks!
Good news and bad news.
Bad first: you’re right. No sugarcoating available.
Good: you can make it work with relatively small changes to your workflow in most cases.
Well known that clipping masks don’t work reliably in the UI. Use the clip to make a rasterized graphic, and then import it back into the document. Not ideal, perhaps, but it’ll get you on track until such time if/when clips are supported.
Also well known that layers are ignored. The UI uses colors to determine separate jobs. Search the forum for “custom palette”, it will make your inkscaping a lot easier.
I think the original post was more geared towards using z-index (stacking order) to knock out objects below.
To @sqw: SVG 1.1 doesn’t have a z-index. The spec calls for painting/rendering objects in the order that they are coded into the file. All it does with an onscreen render is paint an object on top to simulate knockout. You still have the object below.
If you want to knock out objects below, you need to learn to use Pathfinder or Boolean operations. Or, rasterize the object so you get a WYSIWIG.
Yes, that is what I figured, why I tagged it as Inkscape/SVG.
It’s flipping useful I know that!
Boolean can’t always do what you want by with off clipping.
And rasterising isn’t always the answer either.
I have to say that I have yet to find a path/process I couldn’t boolean/raster my way out of. I’m curious what cases you’ve come up against where it’s not possible? I’m not saying you’re wrong, I’m just saying that I haven’t come across it yet(*), and would love to know so I’ll be prepared for when I do come up against your case.
@jbmanning5 you clearly have better reading comprehension than I do 
Good point. But, back to @sqw, in those cases, I generally use “exclude” or “combine” (depends on the paths in question) and don’t have a problem.
(*) I have had some frustrating times with cutting heavily layered paths, because it’s a bear to “weed” out all the orphaned path bits. I am still trying to think of a better way to deal with complex open paths and cuts/divides.
I have to add - the cut order that is actually processed is incredibly strange.
Does not follow the order of items in the SVG, if you cut and paste items and print at one go it jumps from one to the next and back again, quite randomly.
Be really nice if the cut order was the order of the elements in the SVG then at least you could control which way the wind is blowing against the cuts.
I think it is?
Someone posted abut ways yo wrangle path direction and order to impact cut direction.
I’ll have to go look, hang on.
You can control it.
Color code the elements then in the GFUI you can order them however you like.
Having to do clips, color traps and path knock-outs are pretty common workflows required for printing processes like screen printing or offset press, and also other CNC operations like vinyl cutting, routers, mills, plasma cutting, etc. Having to do so for Glowforge projects isn’t anything out of the ordinary and will become second nature as you get more practice and seat time with the software.
Yes, such a simple tweak to improve efficiency. However, definitely not what I’m seeing here.
Yes, you are right about the colours and indeed clips etc.
That doesn’t explain the random walk that is the actual laser cut 
Laser cuts produce heat and when you concentrate too much heat in an area, you get material warping, so cuts are spread out to reduce that possibility, when possible.
Here’s the thing also. They haven’t worked extensively on cut path optimization. It saves a minuscule amount of time. My example above shows that. I saved one minute on over 500 inches of cuts. That’s like what, 5%?
It takes longer to self-optimize the file than the time savings. I do it because I cut a lot of the same things and it eventually adds up.
That is true. On a 12"x20" bed, path optimization just does not save much time.
I get optimisation isn’t huge, nor would I put it at the top of the priority list. On the other hand, it is (a) trivial and (b) done on the big cloud server, so for not a lot of coding for even a couple of percent improvement in cut time I’d take that.
I’ve said this elsewhere, but cut a living hinge and it a lot is wasted head movement.
LMAO over that one. Route optimization is one of the hardest problems in mathematics. Google “traveling salesman problem” and prepare for a rabbit hole. Laser path optimization is just a specific case of that class of problems.
I call BS, the random cuts of the GF are not to reduce heat. I’ll try and put up a video later you’ll see what I mean about random.
Fundamentally, I think that the sort algorithm used to group the cuts/scores/etc by colour is messing up the SVG sequence, what it needs is just to optimise it while it is doing this.
Not true - in fact google does exactly that when you ask it for a route over several stops.
I know, because this is the exact area of work I am in right now. I’m not asking for a perfect optimisation, I am saying that you can optimise maybe 2 - 5% speed for trivial coding and no, it is not at the top of my priorities, but yes we would all get a faster GF because of it.
Now, you might make arguments about actually not optimising for speed, but instead for heat dissapation, but that is a different problem altogether.
@dan has made a few comments (the most recent was literally today, to you, so I’m not sure why it’s coming up here too?) about how optimizing paths between cuts doesn’t really net you much of a time savings.
Today:
specifically about traveling salesman…
More reading…
https://community.glowforge.com/search?q=%40dan%20optimize%20path