Hi there, I am trying to create a data set that adds numbers automatically into a grid, like 1,2,3, etc etc. the numbers are curves with up / down movements ( I want to draw them on a robot) I tried to convert them into sets, move them to area in grid, so far nothing really works. Any help or suggestions much appreciated.
Thanks , Ekke in Hong Kong
Not sure where you want the comma.
Edit: Hmmm I see you probably want the numbers running from top left of the grid. If you can restructure your grid so the points are in that order it should be easy enough to implement this code.
I don’t have your plugins but this might help move the project forward? There are issues with point sequence that mess up the letters.
P.S. Just noticed that if you right-click CullPt and choose ‘Leave One’ instead of ‘Average’, it affects the point sequence.
02.Calig_REV1.gh (75.9 KB)
Dear FTZUK and Joseph ( nice to see you again!) I had to combine aspects of both scripts to make some progress, I used Josephs’flattened data base and combined it with FT’s script ( with some changes) I need to get points, not curves at the end, as the robot uses frames to move ( point to point) , hence the interpolation messed up the curves. This works already really well, what I need is automated addition ,so that the numbers increase through the grid with coma separation in between ( so I can see the individual numbers better) The last grid item piles the numbers up though, so I guess there needs to be a cull option ?
However, this is great progress, I can scale the numbers and move them into the right place, automated addition with coma separation is something that I need to resolve, any suggestions are very welcome…
Perhaps you might know the painter Roman Opalka, who, for a lifetime, only painted numbers ( Roman opalka art - Search Images (bing.com)
I want to recreate this using my robotic system
Sounds like a nut 
If I cross-reference with multiple sub-lists then the grid gets full if there’s enough numbers without overlap, and if the grid is too big the numbering stops depending on amount of numbers. Still not sure where you want the comma.
Edit: That Move2Pt should really be a native GH component.
I don’t think anybody understands what you mean by this.
Hello
not sure to undestand well what you are after. I have made 2 components in Nautilus that packs geometries in a grid.
Or you pack while having the same size of the input geometry
Or you can use a geometry
pack geometries.gh (7.8 KB)
Pack on sized grid is useful if geometry have different sizes.
And with commas and points
Dear Laurent,
The node in your Nautilus Plugin works a treat, a very simple and neat solution. However, I do want to use my “calligraphy numbers” rather than your text generated numbers going from the single digit to infinite numbers using my “calligraphy numbers”.
Orientation of the numbers as well as the comma is not important at this point.
Thanks again everybody, your help is much appreciated!
Might also be easier to convert your calligraphy numbers into an actual font, then you could probably use @laurent_delrieu script and specify your custom font.
Or similar software.
I will look into it, thanks, but the numbers created have a high (in Z direction) entry point on all strokes, imitating the brush approaching and leaving x/y plane. It is more a three-dimensional geometry rather than flat lines I try to multyply
I would separate “brush” movement from creating the points for each character, the “font” should be flat!
I don’t think it is too complicated to transform all your symbol to polylines. A list of polyline per branch.
So here an integer is transformed to text in order to be splitted then a list of displacement is done for each letter
I have looked at this and played with it several times but set it aside each time because there are so many problematic issues. Nearly did so just now. I don’t like posting code like this but here it is:
P.S. “1” looks better if you skip CullPt but that breaks other characters. Replacing IntCrv with PLine sorta works? But as I said, the results are discouraging.
(grid size increased from 200 to 240)
Dear Joseph,
I had to work all day at the University, but managed to have a quick look ( and hooked it up to the remaining HAL code,) this looks VERY GOOD, congratulations! Yes, there are issues with the interpretation of Nr. one and the robot does not close the zero, but I think I can figure this one out myself. The number addition works great, I want it move from left to right, but that I should also be able to conclude.
I hope to run some physical tests with brush and robot and hope to upload a picture of a result here soon.
Again, thanks to everybody who contributed, this certainly was a bit if a bxxxx to figure,
From Hong Kong with best of wishes
Ekkhard
I refactored this code to organize it into three functional parts:
Font creation is unchanged - it’s still broken, sideways and in a grid of its own. The purple group orients all the font characters at the origin, based on their BBox center points.
Grid creation uses an arbitrary plane for RecGrid and copies that plane to the center of each grid cell as locations for the numbers (text) from Series. The location planes don’t have to be in a grid at all 
They can be planes in a circle, spiral or whatever.
Placement / scale / rotation happens in this white group using the font, text and planes from the first two parts.
To modify this code, it’s very important to understand how all three parts work together
P.S. IntCrv and PLine both work because the font is broken. When fixed, one or the other should suffice.
P.P.S. This is a quick demo of an alterative to the grid layout. Scale factor is 0.140.
By the way, the points are at each location, they are just not shown.
More…
There is always more that can be done with software. This is identical to version ‘b’ except I split off the orange group (“layout”) from the white group (now labeled “words”).
The white group manipulates font geometry at the World XY origin, where it was put in step 1 (font creation). The orange group orients “words” from the white group to the plane locations.
Dear Joseph,
this is a very substantial piece of work here, I need to find a bit of time to break it down to fully comprehend your work, the complexity is substantial. I run the robot on vertices and planes, so I actually do not need the interpolation/Polyline at the end. The endgame for me is to be able manipulate individual vertices on their plane data, that the brush following the data points can enter the x/y plane at various angles, recreating the real flow of a brush. I think, your script will allow this. This is some serious outcome here and I do not want to take credit for it, this might end up in research outcome and potentially papers, as this code will be very helpful to collogues in our (Chinese ink ) department. I have no idea whether you do this for sole fun or if you work in a research environment, but please let me know how I can quote you on your very substantial input here. I keep you posted, and, again, I am seriously grateful for your help.
My intention with the refactored code was to simplify and clarify.
I used PLine because it works with your font points while IntCrv fails.
This is a public forum so you can use and “quote” (?) anything.
I modified your NR.5 cluster by replacing the last Merge with Entwine:
I believe these three curves are what you expect your robot to follow:
These separate curves (paths) are lost when the points are flattened and merged inside the NR.5 cluster. Maybe you intend to fix this somehow after the fact by separating the raised end points? But I think it would be easier to preserve them, eh?
Perhaps I’m wasting my time but I would do it this way:
That is the NR.5 cluster above. To be thorough I modified all your font clusters. One more Ungroup in my orange group is now required, and to keep it happy, I added an extra, superfluous Group to all your font clusters that don’t really need one, since they have only one path. As you can see in this image, only three of the numbers have more than one path: 4, 5 and 7. (I see no reason that 7 needs two paths?)
I made fixes to “1” and “3” because they looked broken.
You can enable IntCrv and see problems that remain, which is why I used PLine.
Come to think of it, none of the digits (0 to 9) need multiple paths to draw them, eh 
Some letters of the alphabet need multiple paths (strokes) but not these digits, unless you want to underline some of them as OpenNest does for 0, 6, 8 and 9:
So why go to the trouble of separating paths in single digits? Perhaps to ensure “kinks” at appropriate places from IntCrv. That makes sense to me.
But why add vertical lines in the font clusters at the start and end (entry and exit) of paths when those points can be easily derived later?
