RE: offset width modifying
looking in the inkscape code, seems to me that this requires the creation of a SPShape derivative, like the SPSpiral is, and the storing of the path whose offset is considered as a attribute. i already coded a working solution with a SPOffset object, and a sodipodi:original attribute (the width is stored as a sodipodi:radius), but i dunno what clearance i need to do such additions: is it OK to add attribute types and objects classes at will? is there a guide explaining what behavior is expected for these?
Please clarify: As I understand it, you plan to change the current inset/outset menu commands and shortcuts so that:
- when applied to an arbitrary shape, they convert it to SPOffset and set some initial offset attribute value,
- when applied to an SPOffset, they simply modify its offset attribute and regenerate the visible shape from the same original shape?
Is this your plan? If so I think it could work, and would provide a nice solution to the problem of "shape degradation" when in/outset commands are applied multiple times.
One problem that I see (but may be you already took care of that): our SVG must always remain renderable, and it must render the same in any other SVG renderers. This means the d="" attribute of the SPOffset object must store the _already offset_ path, not the original path. For storing the original path, you'll need a separate attribute in the inkscape: namespace.
Other questions: It would be very nice to be able to edit the _original_ path with the node editor without losing the SPOffset status of the object, i.e. have the visible offset contour to be updated automatically when I edit the nodes of the original contour. Is this possible or if not, do you think it's easy to implement?
Also, it would be very nice to be able to convert any other SPShape derivative to an SPOffset without losing its original status. For example, being able to edit a rect (e.g. rounding its corners) and see the outset contour updated at once. And it would be extremely useful to be able to apply SPOffset to text objects without converting them to path first. Is this possible with your current model?
Well, even if not (i.e. if node-editing of an SPOffset loses its offset status and original shape, and if SPOffset can only be created from a path), I think it's still useful, so let's try it out. Whether to commit it depends on how disruptive it is; if you didn't change much outside of your domain and don't expect other things to break, go ahead and commit it; otherwise please create a branch for your code (see Wiki for instructions) so we could test it.
P.S. Please cc: your replies to the list so that everyone else can participate in the discussion. Also, please add yourself to the AUTHORS file if you didn't already, and please document your changes in the ChangeLog.
_________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
renderers. This means the d="" attribute of the SPOffset object must store the _already offset_ path, not the original path.
that's what i suspected; it's been coded accordingly
edit the _original_ path
maybe when i understand a bit more about the inkscape internals, cause it requires to catch modifications to the object you link to (the original one)
commit it; otherwise
done
please create a branch for your code (see Wiki
cvs n00b here, afraid of messing up with cvs branches...
a note on knot editing of objects: when doing modifications directly in the xml tree, the knots are apparently not refreshed (see the spiral and the sodipodi:t0 attibute for an example).
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
participants (2)
-
bulia byak
-
fred