Not yet satisfied, I changed it from the usual rectangular shape to fill any object you care to draw! With this one constraint: curved edges are converted rather bluntly into straight lines. It won't work on a circle, for example (this will be 'straightened' into a rectangle), but it will work on, for example, a 5 pointed star!
Each small rectangle is about 5 mm wide and high, so make sure your object is large enough.
Download the code from my website: http://www.jongware.com/binaries/mazes-everywhere.zip
Start it in a blank document with no selection to get a crude "width/height" dialog, or draw a rectangle and have it selected to fill it with 5 mm wide maze paths. If you're feeling experimentally, draw polygons, or tack together a few shapes and combine their paths into one.
And if you're feeling really courageous, experiment with how to get 'holes' in your maze!
This one started out as Arial Black text, tracked to join the letters together; then it took some tries to get the "winding" of the holes right. (Techno-babble: There seems to be a bug in my code that doesn't always seems to return the correct winding order.)
I couldn't make it work with text like you did with the letters in your name. I don't do fancy scripting like Jongware, but for anyone else wanting to put the maze into text, I would suggest:
If only I could get the winding order stuff right (Wink, wink!)
But you can solve it the same way I did (at home): Buy a Mac
Yeah! I know what you're talking about. Specially with scripts that use a huge amount of pathpoint calculations/transformations. I'm still looking for a solution to monitor InDesign JS memory leaks experienced on Win64 platforms...
Draw a rectangle. Then draw another rectangle inside this. Select both, and combine the paths. What should happen -- should be smaller rectangle be joined to the larger one (because the large one is 'around' the small one), or should the smaller one get cut out?
"Winding order" is the name of the following convention: if you follow a path from its first point to the next, and the general direction is clockwise, the inside should be filled. If the general direction is anti-clockwise, the path should be 'cut out' (of whatever it is on top of).
You can experiment with this in InDesign. If you type the letter 'O' in InDesign and convert it to outlines, it will consist of two paths (actually sub-paths). The outer one is set to be filled, and the inner one is set to be 'unfilled', cut out of the larger one. The entire path is divided into two sub-paths -- you cannot see a thin line connecting the outer to the inner circle. This is what InDesign calls a 'combined path'.
Now what happens if you release the sub-paths into their separate components? Suddenly, you can move the inner circle around on its own -- and it gets filled, and that is because the default for a path on its own is to be filled. The winding rule doesn't apply because there is nothing 'in' or 'around' it to be cut out.
[*] There are areas in math where I don't need to do the calculations and immediately 'see' something works or not. A colleague asked of the mazes, "Are they all solvable? No loops or dis-connected parts?" I can confidently say that is the case -- because, for me, this logically follows from the algorithm I used to draw them. No further proof needed, as far as I'm concerned.
Have you tried going from a filled black square and cutting out the boxes (making them white) during your depth-first search? That way the outline of your text will be sharper (and the maze will be harder to solve, since all paths are connected.
Edit: My bad. I thought the white part was the path in the maze and the black was the walls, but it seems like it's the other way around.
Jay, what I did is this:
1. Type in your name ("Jay"), using the boldest, blackest font you can find on your computer. We don't want no pesky Light or Thin fonts for this.
2. Track the text until the letters not only touch but even overlap -- lots. As much as you can, actually, without sacrificing the readability. And Yes: You May Cheat. In "Jongware", the capitals "W" and "A" don't play nicely together. So I just draw a fat rectangle over them.
3. Convert the entire thing to outlines.
4. In the font I used above, the letters "O" and "G" were sparsely build up -- only a few points, the rest is all Curve. I don't like Curves so the script converts them back unto the straight-and-narrow, but in this case the "O", for example, would become an ugly square with a square hole inside it. Fortunately, we have the Pen tool -- all you need to do is add lots of extra points along the curves, so if they are converted to straight lines, the general shape will be preserved.
5. Combine everything with the Pathfinder. That would remove the insides of the O, the A, and the R, so I deselected these first. I made sure the fat connector block between W and A was selected.
6. Next: punch out those holes again. Select them together with the large block and do some path-finding again.
Steps 5 and 6 aren't strictly necessary, but it seems my script has some problems with determining what ought to be filled and what not -- I've seen it fill up the J and O, then stop on the N because it thought that was an 'N-shaped hole'. Combining everything into a single large object prevents this. It also makes the next step easier:
7. Have the object selected and run the script. If holes get filled anyway, delete the maze, select any point in that hole with the white arrow, and select "Reverse Path" (under Object, Path Operations). Repeat until it %$! finally works. (You have to do this by trial and error, and it bugs me enough to have a second look at the code!)
8. Tinker with backgrounds and fill colors. The In and Out in the image above are just two random rectangles, stretched out to look like entry and exit points
Those dastardly doers at Adobe! What was called PointType.LINE_TYPE in CS4 (and at least in CS3 as well) suddenly, and for no obvious reason, now ought to be referred to as PointType.PLAIN in CS5!
To be honest, that's just an educated guess. The LINE_TYPE has gone AWOL in CS5 but it gained this new type -- it's a fair bet the usage is the same. You can safely change that line and replace LINE_TYPE with PLAIN, but it's a sort of long shot because there might be other incompatibilities.
Good thing I thought of adding "CS4" in the thread title -- not guaranteed for other versions!
However, if it does suddenly spring back to life with this one change I can re-write the script to have it check the version first and do the appropriate thang for both CS4 and '5.
Now isn't math fun?
It took me hours to devise a way to convert a 'carved' maze (one where every 'cell' has doors in other directions) into a 'walled' maze (one where every value tells if there is a horizontal or vertical wall somewhere). Converting between the types is not as straightforward as one might think ...
It took me so long because I wanted it as perfect as possible. It was easy to draw one vertical and horizontal line per cell, but that leads to thousands and thousands of little line segments. Now the longest possible lines are drawn, going around corners where needed. A nice side-effect is that you can set corner options -- the rounded ones look especially nice.
Another problem was with curved lines. I already had some code to convert them into straight lines, but I ran into problems with the weird 'entirePath' stuff -- the order of anchor point and curve indicators is not as logical as you would think. (That took me an additional couple of hours. Oh well.)
So now you can draw circles, ellipses, and otherwise curvy thingsies, and fill them with mazes:
Download, as usual, from www.jongware.com/binaries/line-mazes-everywhere.zip