Text curve generator component with good tree structure output?

I’m working on a script that takes text curves generated in Rhino and converts them to my own system for using a CNC router to build very large prismatic letters from MDF, plywood and wiggle wood.

One thing that would be very very useful is a text component that outputs letters with good tree branch structure - meaning that a lower case J’s dot and tail would be in the same branch, and the interior and exterior curves of a capital B would be in the same branch, with the exterior curve always being the first item in the branch.

Is there any plug in that can do that?

It’s not difficult to write a script that separates the interior curves and exterior curves, but I can’t find a way selecting a large block of text curves and putting them into one curve component and keeping the dots of Js, Is and ?s together with the main part of the letter/symbol.

Not sure if I understand the problem correctly because first you say you take text curves from Rhino and then you look for a text component that separates text. I think this can be done quite easily by splitting up a text into a list.
In Python


I have been taking text curves from rhino, but it’s obvious that theres no way to do that and keep separate curves in the same letter together, and therefore I was hoping for a component that can do it by taking text from a panel and font from another input, like some old plugins that are now unsupported in rhino 7 did for previous versions.

Not sure that I got correctly the issue but:

Each letter is a collection of an outer and maybe some inner curves. Clustering text/“words” in some Crv Tree with any rule imaginable is elementary via code (or you can use Brep.CreatePlanarBreps (IEnumerable(Curve)) and then get the BrepFace (brep.Faces[0].DuplicateFace(true)) and then the related inner/outer Loops). That’s kinda flying from DC to NY via LA … but who cares?

That said - if you want - you can collect your crvs in a Tree with 26 first dim branches where the second dim contains the instance of a given letter in your text/“words” … or use 3 dims (first indicates the “word”) … blah, blah.

this could be a way (using opennest)
text_to_tree.gh (10.0 KB)

1 Like

I’d assume you have curves without really knowing what character the curves are…

The centroid of an inside edge of an ‘a’, ‘d’ or ‘p’ are always within the bounding box of the outer edge. In english language I think ‘i’ and ‘j’ would be the exceptions. The dot is outside the boudning box of the main curve of the character. However we can put a larger rectangle on each centroid and check which of them are inside and then remove duplicates.

character_tree.gh (19.7 KB)

1 Like

Here is a Python approach. The method I have used seems a little over complicated, so there is probably a more efficient approach. It does looks like a similar method to the one used by @martinsiegrist however.

Python_Text_DataTree.gh (23.3 KB)


Right. I just use the boundary surfaces component and sort the surfaces’ joined edge curves by area in order to put inner and outer curves into the same tree branch. Easy.

The tricky part is keeping the dots on i, j, and ?, as well as diacritics and such in the same branch as the main part of the character. And of course with many non-latin scripts it’s much worse. Many multi-part kana and kanji, for example.

No this is NOT the way to do it: Imagine an O with a freaky inner curve (say: petal style). That has greater Length than the outer … but still is inner. The only safe way is to use the RC Loops Method.

Other than that if you approach this puzzle solely via code … there’s no tricky part. For instance you can do things the likes:

Or group - so to speak - chars according their ASCII value:

I said I sort them by area.

It’s impossible for a 2d curve that fits inside a coplanar curve to have a larger area.

We had a similar problem and took a very different approach in the end. We actually built our own character set, meaning we create the curves for each character, so we are able to edit them by hand. The set of curves for each character are turned into blocks in Rhino (this is all done with the help of GH of course) and custom data added to each character block.

Then we basically re-assemble the blocks from text input using measurements stored in the custom data for each letter.

In the end we solve the problem of having any number of curves per character (there are a lot more special cases in non-english languages and symbols than just i and j) as well as the fact that Rhino text can’t do proper kerning of characters (we needed each character to basically touch the next one).

We played around with all sorts of text to curves components, plugins, etc., but in the end building our own system was the only thing that worked reliably.

1 Like

I often have to deal with fonts that are a brand’s identity font. So I’ve worked up a GH definition that helps me “clean” them. Spotting discontinuities within curved sections, spotting curved segments that should be straight, spotting lines in the crotches of Rs or Vs that are so short that I’m better off eliminating them. Stuff like that. So far works quite well.

And so far the second part of the process, which identifies curved segments, straight segments, and where they intersect either on a tangent or at a crisp angle, and a bunch of other variables and decides where to place ribs, solid plywood and wiggle wood based on the variables, it working OK.

It’s not completely automatic, but I keep finding ways to make it more automatic. At this point it saves me a lot of work. But for jobs with a lot of letters, labeling would help a lot, and that’s why I’m trying to group letters with more than one part.

1 Like