GNOME Bugzilla – Bug 347677
PDB interface for stroking vectors
Last modified: 2006-10-28 11:15:12 UTC
There is no way to stroke a vectors object via the PDB presently. (and 'stroking' a vector by feeding the output of gimp-vectors-stroke-interpolate into gimp-paintbrush does not perform antialiasing with acceptable quality.) The only likely-looking PDB entry ('gimp-path-stroke-current') seems to do nothing. Ideally two PDB entries would exist, one stroking the entire vector and the other stroking a single component. Naming them seems difficult -- the existing names would suggest 'gimp-vectors-stroke' and 'gimp-vectors-stroke-stroke' which are straightforward but ambiguous.
gimp-path-stroke-current() seems to work for me (it just gives a deprecation warning now). There now is a new PDB API: gimp-edit-stroke-vectors() takes the target drawable and the vectors object to stroke as arguments. I do not think that it is feasible to individually stroke GimpStrokes, at least it is not easily supported by the current vectors code. It however is now possible to use gimp-vectors-stroke-get-points() and gimp-vectors-stroke-new-from-points() to create a duplicate of the stroke in question for a new vectors object, which in turn then can be stroked. Since this bug deals with the PDB interface I will close this bug now. However, since gimp-path-stroke-current is supposed to still work, please try to find a way to reproduce it. Esp. make sure that the current foreground color is visible against the background of the current layer and no weird paint mode is active while you test it. It worked flawlessly for me.
ah, I wanted to ask you to file a new bug report if gimp-path-stroke-current indeed does not work for you. Thanks.
I suspect it works as you think I want it to work. It paints using the current drawing mode, color, tool, and brush. (which is probably the reason I thought it did nothing -- it must have been set to the wrong drawing mode.) But how I want it to work is, exactly like the 'stroke path' dialog. Allowing the specification of thickness, cap and join style, fill pattern, and true antialiasing rather than coarse-grained brush subsampling. As line angle approaches 45 degrees, brush subsampling degrades the result more and more versus vector-based antialiasing. The details of the PDB interface: It's clear to me that the custom dash configuration amounts to an array of 24 booleans. Typically one would want to avoid specifying this each time, and use presets instead. I assume this would work best as a variant of the base function (xyz and xyz-custom) I can see how this bug remained unaddressed -- it wasn't very understandable. Do you think I should file *the above* as a new bug report, then?
You are right, a free specification of the stroking parameters is feasible. However, as you already noticed, this really is a massive amount of parameters that would have to be specified. The whole stroking thing needs a complete overhaul in the PDB, even to the extent that probably the PDB needs to be redesigned to support keyword arguments. When I discussed this problem with mitch some days ago, the consensus was, that we postpone these changes to the next development cycle, to get 2.4 ready for shipping. That unfortunately means, that the advanced stroking features will be unavailable in 2.4. So yes, I am aware of the problem but I won't fix it for 2.4, since it is IMHO too much of a mess. IMHO it would not hurt, if there is a bug report for this issue (I did not check if there maybe already is), but it is not strictly necessary either. We are aware of this and we want to fix it, just not for 2.4.