Not a Glowforge person nor is it officially documented other than threads on this forum but here is the color ordering. It’s based on Web hexadecimal values and the GFUI orders them such that colors towards the left are last and colors towards the right are first.
Based on what I have seen, the algorithm that defines the order does not necessarily choose the same order for the same project every time. It could run a different order each time you run the same job.
This doesn’t make sense.
First there is no standard thing called “WebHex” colors (best I can tell it’s the name of one of the default palettes in Inkscape, which I’ve never used). There isn’t even really a think called “hex colors”. There are 24-bit RGB colors which can be represented in hex, which is how you specify colors on the web. But they can also be represented in other ways such as rgb(0,102,51) a nice evergreenish color, also rgb(0%,40%,20%). There are 2^24 24-bit colors or about 16.8 million of them and that’s not counting 256 levels of opacity. Colors outside the 24-bit range can be specified with rgb() but let’s ignore that.
Second, there is no canonical order of colors, not surprising since RGB colors occupy a 3-dimensional space. There isn’t even a canonical order of the 216 “web safe” colors that are almost completely irrelevant these days — for example, these pages present the web safe palette in three different orders (Color Chart — HTML Color Codes, websafecolors.info, Web colors - Wikipedia). Also, since the 216 web safe colors all have names, some sites present them in alphabetical order.
I find it hard to believe that Glowforge would implement an algorithm that only works for the 216 web safe colors or relies on the colors in a particular “WebHex” palette in a particular application.
I could believe one of these:
Has anyone done a large enough test to know for sure or does anybody from @glowforge want to enlighten us? Thanks.
I believe I’ve seen this too. Given that the Glowforge people are pretty smart and have done a lot of things right, I can’t believe it’s random. Perhaps another variable is head speed? Or material?
There are multiple threads on this forum regarding setting up custom color pallets for Inkscape, CorelDRAW, Illustrator and Affinity Designer specifically for controlling the order of operations that the GFUI loads… even already mentioned in this very thread with a direct link.
And I’ve been using these colors daily for over a year. It’s well tested. I know it works. Multiple other long time users know it works.
My bad.
Not sure what your point is as far as naming elements in AI. That’s a gimme. Is that how you propose Glowforge should allow you to define the settings? If that’s what you really want, you should post the suggestion in #problems-and-support.
I can see a lot of inherent problems with that with the way Glowforge defines operations (by color).
I’m adding this comment here mainly for anyone else who comes across this thread. See the other thread I have linked to.
The named colors above was not useful as “dark blue” (e.g.) is not well defined. There are many dark blues. However, I did find this post which I had missed earlier (when I found this one): Custom Inkscape, Illustrator, CorelDraw and Affinity Designer Color Palettes for ordering operations in GFUI and it contains hex and numerical values for the colors listed above. Based on that, it looks like my guess that sorting could be by R, then G, then B, is correct. This can also be looked at as sorting by the entire hex value, if you have that value available. Given this, I don’t need a palette.
Names/ids are not ideal but I think it may be the best solution given that GF doesn’t control all the various illustration products.
For engrave vs. cut, GF has done what every other laser cutter does — differentiate fill vs. stroke. Currently, score is manual.
For order of operations, they really only have two choices: 1) order in file (back-to-front or front-to-back) or 2) color. I actually like color better because it is easier to control. My only complaint is that it’s not documented anywhere.
For manual override settings, I can only think of two things that would be internal to the file: 1) names/ids, 2) a special visible text block that contains instructions and is ignored for cutting purposes. That might be cool but would be pretty hard.
