On Wed, 22 Mar 2006, bulia byak wrote:
On 3/22/06, ted@...11... <ted@...11...> wrote:
Okay, perhaps I'm confused. The path effects stuff is adding operations that will execute when a path is edited. So, this would be like an effect, but limited only to single paths. I guess I think of this more like 'brushes'.
I'm not sure "brushes" is a good term. Its primary uses will be any effects that take a path and return another path. This includes all kinds of randomization, fractalizing, smoothing, rounding corners, distortions, etc. etc. It's not specifically for doing something to the stroke, which the "brush" implies. What it is is a generic path twister. The only prerequisite is for the object to be a path (or a shape, which is internally a path). That's why we call them Path Effects.
So you can control how the path is drawn, by having a custom operation edit the path based on the core path.
Not even "how it's drawn", but more generically "what other path is drawn instead, based on this source path".
I see your point here, I was just looking for something that didn't have effects in the name. And, well, GIMP has a brush that draws with leaves :) Path Effects is fine, I don't think there'll be too much confusion.
BTW, I'd love to see the caligraphy tool refactored in this way, so that you can move the line, adjust the tilt, all after the line had been drawn.
Yes, eventually this fits into path effects as well. You take the source path and some parameters (widths array) and you create another path (variable-width stroke) to display instead.
I was thinking a little differently. Where the data would be the path and the pressure and tilt at each point on the path. Then you could generate the width and resulting path from there. Then, we could create some on canvas editing widgets to adjust tilt and pressure. It might be interesting when defining the API to assume that they'll always be there (pressure and tilt) and then set them to full and 0 degrees if the line doesn't have that information.
If however your mapping is not 1:1 (e.g. blend), then the Path Effects are of little help. You need a new SPObject type for that, typically a derivative of a group with specialized properties. In fact, even envelopes are best implemented this way too, not as path effects, so that enveloping is possible not only on single paths but on groups. I have another plan for that, which you can read here:
I wasn't thinking we'd need to go that complex. I thought just listening on the source paths. Kind of a 'loose' association instead of creating a new object. Though, a new object would solve some of the problems I had...
As for making the path effects into scripts, I think that would be cool. I think that the only thing that would be required is having one "easy to use" entry point. Something like:
string mung_this (string in);
Where both of the strings are the list of points in the "SVG d style".
You also need a number of parameters, whose number and interpretation will vary by effect.
Well, if we subclass from the Extension object, there is already a list of parameters. Currently the parameters are per-user, but I've designed it with the plan to go per-document and per-object with them.
On an sorta unrelated note: It would be really cool if someone made a font where all the characters were a single path for use with this. Then you could write some text, and easily use a 'brush' on it.
Convert any text to path and combine the paths (in fact they are already combined, currently which needs to be have been fixed 100 years ago).
That will give you the outline of the text in the font. I was thinking a font that will give you a path that is just the "line in the middle".
--Ted