I sent support an email about this and their response was lacking to say the least. Basically they said the problem was with me and my file and not them. If that were the case, why does the UI render it perfectly fine? I work in IT and I can tell you at the companies that I worked for that would not be an acceptable response. A bug would be opened and prioritized.
Seeing how GF refuses to acknowledge the bug and puts the burden on the paying customer instead. How do you fix this? How do you prevent this before ruining GF materials? I mean these aren’t cheap materials and the subscription is not cheap either. I just don’t want to keep wasting money on material only to find out I ran into another ‘Feature’.
In spite of how you feel right now, which is understandably frustrated, it is likely in your file and not a bug in the UI. If you’d care to attach (zip) your file here, I’m sure other folks would take a look at it and try to help you with this.
@awebs76, @Xabbess since we are hopping on the ‘It’s not a bug’ band wagon. Here is what I am going to say. Either there is a bug in the UI or there is a bug in the processing stuff that sends everything to the GF. If the UI won’t show what the GF is actually going to do, what good is it?
GF is billed as a WYSIWYG device. What I see on the screen is a design that does not have the stray line. What I get in the end is. The fact that what the screen shows and what they GF actually does is the problem. If you are going to sell your product as a WYSIWYG, it should truly be WYSIWYG.
You say there are errant paths? How do I find these errant paths? The fact that this ‘isn’t a bug’ means there should be an explanation on how to find the offending items.
@dklgood I have looked for stray nodes but I don’t see a single one. The fact that you say sometimes it will draw the line and sometimes not indicates to me that this is a bug. Code is predictable. It is logic.
So are you saying it is a bug in the GF processing system?
Personally, based on other ‘features’ the UI has introduced, I am more inclined to say the bug is in the WYSIWYG UI system. It just isn’t showing what the machine is actually going to do.
You say it is the file but the same file is used to render the UI and the GF operation. The two do not match. This is a very simple QA task. If the screen does not match the output, there is a bug, It is just a question where the bug is.
I would 100% agree that there is a bug with the file if the UI output matched the GF output but it doesn’t. You get two different results from the two different systems with the same file.
It sounds like you have already made up your mind that it is a bug. Several people have asked you to share the zip file and maybe they can fix it for you. The community helped me fix one before. Give them a chance.
Very easy way to fix it…rasterize the design. (It can be very difficult to find errant points and open paths in a vector drawing.)
The Glowforge algorithm closes open paths and points when engraving in vector designs, and if there is a stray point in the design or a path that was not completely closed, that can happen. If the parts to be engraved are rasterized, it actually does become WYSIWYG. (Otherwise, the algorithm is going to interpret it by closing the open paths/points using the shortest distance between the two points.)
You have a valid point here. Responses are going to be at cross purposes. Most folks want to assist with providing solutions to a problem. Fixing the file is the one where we have the most agency. Getting Glowforge to change how they process and display vectors is further out of reach.
It sometimes takes me a while to figure how what a person really wants and respond to that. Most of the time, I just am just rerponding to my own needs.