On Wed, 22 Mar 2006, bulia byak wrote:
> On 3/22/06, ted@... <ted@...> 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
>> 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
>> 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".