A bit harder than expected (for closed strokes, the parallel stroke should be going in the other direction if we want a selection between the two).

- Create ROD with Kozuka
- Path from text
- One call to script to add parallel strokes to all strokes at .5 pixel distance
- Selection from path
- Drag gradient across



Now back to tackle the open strokes (they have to be transformed in ribbons)

Nice sunny afternoon here... took the time too shoot a couple of photos

Ofnuts you know how there is that smell before rain? I do believe it is coming your way

It's possible to fill the selection with color and have it only 0.5px wide?

Is stroking the text to path with a 1 pixel brush wider, or when your selection is filled, does it end up being 1.0px wide?

This is the path stroked with a 1.0px paintbrush and using a gradient.

Oregonian,
Pixels are dots on your display.
They cannot be cut in half.
So the number of pixels must always be whole numbers.
Gerard.

I was wondering about that open stroke for paths, because from my understanding, any consecutive selection in or outside of the original selection (from a path) would remain "underneath" the original, unless it intersected inversely.

Painting is always applied to complete pixels, but I think this actually leads to faint colors (I have not checked but the selection channel must be less than 255)

Where might one find this script?

Thanks ofnuts
I will be donning rain-dance gear for the next few days ... just a heads up.
Meanwhile . .. enjoy the sunshine.

Saulgoode:

I think he is currently working on it and hasn't submitted it yet.

Yes, having a real hard time with the open paths; looks like there is bug in in Gimp.

So that means Raindance gear correct? Start broadcasting flood warnings now, and get the Ark plans from O, that I do believe she was either planning on ordering or ordered somewhere due to Oregon floods

If you are using 'gimp-vectors-bezier-stroke-lineto', be aware that it adds the line to the beginning of the stroke.

Exactly... this is something I don't understand... why is it working that way? Should I add the points directly?

The reason it works that way is because the path is stored in a "linked list". This means that for each point in the path, there is a data object which contains not just the point's information (for example, its control handles and anchor coordinates) but also a pointer to the next point in the path. This way, the computer only has to remember the memory location of the most recently added point (for example, in a variable named "listhead"); it can retrieve other points by following the links from one point to the next.

Now when you add a new entry to linked list, you can either add it to the beginning of the list or to its end (well, you could insert it to some arbitrary location in the list, but let's ignore that). To add an entry to beginning of a list, you just have to create a new object (by allocating some memory), set its pointer field to point to the original beginning of the list (the contents of "listhead"), and then update "listhead" to point to the new object.

However, to add a new entry to the end of a list, you must first walk along the entire length of the list, following the link from the first point ("listhead") to the second, from the second to third,... until you reach the end of the list. You then can allocate some memory for a new object, set its pointer field to indicate "end of the list", and change the pointer field of the list's last object (the one you "walked" to) to point to the new object.

There are three main reasons that placing new entries at the beginning of a list is advantageous. First, it operates in fixed amount of time because regardless how long the list, it will always take the same number of steps to execute. Second, it takes less time since there is no need to visit every item in the list in order to reach the last one. And third, adding a new entry doesn't modify the existing list at all (this if often a useful feature, but doesn't really matter for GIMP paths).

One could overcome the first two limitations of appending to the end of a list by maintaining a second variable (for example, "listtail") which always points to the end of the list. But I'm guessing the GIMP developers just didn't feel it was worth implementing this functionality. The net result though, is that the most recently added point is always the "first" point in the path (the first point you added is the last point in the path).


I'm not quite sure what you mean, but if you are referring to using 'gimp-vectors-stroke-new-from-points' to create your new path all at once as opposed to iteratively (using "gimp-vectors-bezier-*" functions), the choice is yours. In my Platonic calendar Script-fu, I chose to write a function that reverses the order of a path after it was created, but that was mainly because I had already implemented creating my paths before finding out some of them went in the wrong direction.

I got the same explanation from Simon Bundig on gimp-developer. Given my MS in CompSci and 30 years writing code, I understand the impact of adding things at the end of a list if one doesn't keep tabs on where that end of list is. But I would have though that the designers would have taken in consideration the havoc this creates elsewhere (for instance, you can't iterate the stroke pixel by pixel if you modify it in front of your path) and so would have used a slightly more efficient list type and kept everything in order.

Simon also says that I can read/write the points directly so there.

Oops. I apologize if my response seemed overly gradeschool; I didn't quite know the experience level to target.

Well, all things considered, this is one reason I love wrapmap. It's like making GIMP do something against it's wishes (yes it does suck up resources like a black hole) but it still has those electrons that escape being pulled in and vacuumed into zillions of bits (i.e. it "works" for me).

My only success with paths in this capacity has been with inverse/intersecting paths, so I am naturally curious to see the result of this endeavor.

Endeavour is making progress, now I got the open path almost sorted out, here is a .3pix ribbon from an open path. Still have a little problem with the extremities (have to shave off these splines), and I'm not sure I'm producing the ribbon on the side requested in the dialog, but yesterdays woes are history.



Question to future users: what would be the right place in the menus for this? Filters? or with other path stuff in Select? Unless there is a way to add it in the Path dialog?

Render - Patterns?

If you register your command in the <Vectors> menu, it will be available when you right-click on a path (with that path provided as an argument). It is also permissible to register your command in more than one location:

(script-fu-menu-register "script-fu-procname" "<Vectors>/Parallel path...")
(script-fu-menu-register "script-fu-procname" "<Image>/Filters/Misc/Parallel path...")

The trailing ellipses (...) are customary if your menu command is going to open a dialog. They should not be included if your command executes immediately with no user settings.