Invalid curves created by the TextObject command

We’ve had an issue since back in the V6 days where text created by the TextObject command sometimes produces invalid curves. Running the What command produces this note:

Invalid curve.
Collapsed polyline with 3 points.
(-42.100,-73.243,24.900), (-42.100,-77.538,24.900), (-42.100,-73.243,24.900)
domain = -8.591 to 0.000

It’s not an issue that I can repeat on demand, but it does come up at least once a month. We notice it because it causes our toolpaths to peck at the curve like a jack hammer.

Has anyone else experienced this? I could easily blame my font, but it works 99 times out of 100.

Here is a file with examples of both valid curves (green) and invalid curves (red)

scribe issue.3dm (380.2 KB)

Any suggestions on how to stop this from happening would be appreciated.



Hi Dan - I see - these are closed polylines with duplicate segments - are you saying this only happens sometimes, with the same font?
Explode > deselect> SelDup > Delete will clean up.


The segments are straight too.
I recommend you convert them to chains of Arcs so they convert to G-code efficiently.

If you only send straight lines and arcs to your mill, it will run efficiently.

Hi Pascal,

Yes, the TextObject command usually produces curves that work well with our CAM software. This issue only comes up maybe 1 out of every 100 times. I’ve tried exploding, ungrouping etc. but once this happens I can never get the text curves to behave correctly in our CAM software. We always end up with the excessive retracts. The only solution is to remake the text. We always use the same font so I don’t know if this would happen with other fonts.

Hi Dan - just to make sure… in the file you posted, Explode > SelNone > SelDup > Delete does not get you usable curves?


Hi John,

The green text in the file I posted will engrave efficiently as it is. However, like I mentioned, occasionally the TextObject command produces the red text. I’ve never tried to convert the segments to arcs, but I’ll try that on the red text in the morning.

I guess my real question in all of this is why does the TextObject command occasionally make invalid curves?

No, I’ve tried that. I always end up with the same results in CAM. The only solution we’ve found is to remake the text. It’s an easy fix, but like I mentioned to John, I’m wondering why we sometimes get bad results with the same command that usually gives us good results.

Hi Dan - ok… I am doubly curious - why it happens, and why the proposed fix fails - possibly due to random curve directions, would that do it? If so, Join then Explode after the deletion of the dups may get the segments all going the same way.


I’m going to dedicate some time to this in the morning. Maybe I can determine what triggers the TextObject command to create invalid curves occasionally. I think I’ll also see if I can script a check so if this happens the user will be warned that the curves are invalid before it gets to the CAM programmer.



Did you notice that the invalid text is slightly longer than the valid text, but they are the same height? Can you think of anything in the generation process, or subsequent usage, that might result in a slight stretch?

Hi Jeremy,

Good catch. I hadn’t noticed that. I wonder if the users are manipulating the curves with the gumball and that results in the invalid curves? That would make more sense than any inconsistency from the TextObject command.

I’m going to start there in the morning.



Hi Pascal,

I think I’ve figured out what’s going on here. The good news is that it doesn’t look like there is either inconsistent results from TextObject, or that the Gumball is causing issues. I believe the users may be neglecting to check the Engraving Font checkbox. I can replicate the red text in my file by unchecking that box. When that’s the case, exploding, deleting the duplicates, and re-joining does fix it.

Now the question is why this fix hasn’t worked for us before. I know we’ve tried this in the past and this didn’t solve it for us. I’ll keep investigating on my end. Maybe I will be able to determine that this issue is being caused by a single user, and I can examine their process to see why they end up with unfixable text curves.



1 Like

Hi @DanBayn
I run into this with my cutter. If I have two dup curves nothing gets done that line is skipped. So I made a study of this and found indeed seldup works most of the time except where I might have altered something and the curve is not really a duplicate but could look and be cut exactly like another curve. Mostly stuff that has been split and is rejoined or stuff that has a control point added. Then it’s really troublesome you have to go in and select by hand. That’s why a number of years back I got a script called selsimilar from @Helvetosaur.
I attached a file of what might occur for seldup to fail well not really its fault.

WhenSelDupFails.3dm (40.7 KB)