- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] path effects: our plan
by Martin Owens 18 Mar '06

18 Mar '06

What could a perl developer do to help? I can also do graphics design but I dout that will be of help either. On Sat, 18 Mar 2006 19:09:08 -0400 , "bulia byak" <buliabyak@...400...> wrote: >For those interested, below is the implementation plan for the live >path effects that Aaron, Mental and I have developed. It's pretty >simple and powerful, we just need more volunteers to work on it. It's >currently in a branch in SVN. > >STAGE 1 is documented in a jabber chat from 2005-10-10. It is already >implemented in the branch and seems to work fine (last time I checked, >anyway). > >[19:01:50] <bbyak> well, i think the first thing you should do is >familiarize yourself with SPCurve and Bpath classes >[19:02:16] <bbyak> i guess for you they will be obvious, just another >array of lineto/moveto/curvetos >[19:04:00] <bbyak> then, write a simple spcurve->spcurve distortion function >[19:04:09] <bbyak> any kind of distortion, just to check >[19:04:52] <bbyak> make it a member of SPShape >[19:05:26] <ACSpike> so the goal is to distort nartbpath >[19:05:40] <bbyak> yes, as a start >[19:05:52] <ACSpike> by way of spcurve >[19:06:09] <ACSpike> and stick it in sp-shape >[19:06:15] <bbyak> yes >[19:06:16] <bbyak> then: >[19:06:47] <bbyak> declare a bunch of attribs: inkscape:original-d and >as many attrs as needed to express your distortion >[19:06:50] <ACSpike> I don't understand how I will test this function >[19:06:57] <bbyak> i'll explain that now >[19:07:15] <bbyak> attribs are declared in attributes.h/cpp i think >[19:07:33] <bbyak> then learn the way an SPObject reads attrs from the repr >[19:07:36] <bbyak> it's simple: >[19:07:52] <bbyak> for example sp-path.cpp >[19:08:21] <bbyak> sp_path_build calls sp_object_read_attr for all >attributes it knows >[19:08:33] <bbyak> thoese calls end up in sp_path_set >[19:09:01] <bbyak> which is where you do the necessary changes based >on the attribute string passed to you >[19:09:11] <bbyak> similar functions are in all other SPObjects >[19:09:34] <ACSpike> "necessary changes" = distort path >[19:09:40] <bbyak> we'll start by sp-path >[19:09:41] <bbyak> yes >[19:09:44] <bbyak> namely: >[19:10:05] <bbyak> you'll need to add another member, a boolean flag >in SPShape class >[19:10:20] <bbyak> which if set means that this shape is distorted >[19:10:42] <bbyak> and also you'll need one or more members for >storing the distortion params >[19:10:47] <ACSpike> oh, wife calls, brb. >[19:11:16] <bbyak> then in sp_path_build you add another >sp_object_read_attr for the distortion attribs >[19:11:43] <bbyak> and in sp_path_set, a new case for those attrs >[19:12:19] <bbyak> where you just parse and store the value in the >(SPShape *) path, i.e. this path recast to shape >[19:12:35] <bbyak> and set the "distorted" flag >[19:13:02] <bbyak> those new sp_object_read_attr must go before the >sp_object_read_attr for d= >[19:13:30] <bbyak> then you add a sp_object_read_attr for inkscape:original-d >[19:13:41] <bbyak> where you do the same as in case SP_ATTR_D: >[19:13:58] <bbyak> but insert a call to the distortion function >[19:14:12] <bbyak> after sp_svg_read_path(value); >[19:14:32] <bbyak> then you set that distorted curve as usual, >sp_shape_set_curve >[19:14:47] <bbyak> and then one last thing: >[19:15:41] <bbyak> the sp_object_read_attr for d= must go AFTER that >for original-d, and in it, if the distorted flag is set, you simply >skip reading the d and setting the curve >[19:15:46] --- mental has left >[19:16:08] <bbyak> so that the curve is obtained from orioginal-d with >distortion, when they are present >[19:16:47] <bbyak> that's all for stage 1, i think >[19:17:10] <bbyak> it should work if you manually add the attrs to a >path and it will show it distorted >[19:17:19] <bbyak> and will be generally very instructive to play with >[19:17:33] <bbyak> based on which, it will be more clear where to go next > >STAGE 2 is not done yet, I documented it in a message to Aaron: > >Overall, our Stage II goals are: > >1. make the system capable of handling several different effects, >with new ones easy to add > >2. make sure effects are correctly read in SPPath and in all >shapes > >3. make sure objects with effects are correctly transformed > >4. make sure paths with effects are correctly node-edited > >5. make sure shapes with effects are correctly handle-edited > >6. make sure objects with effects are correctly written and >rendered the same in Batik > >Most of these goals are surprisingly easy to achieve :) So don't >be frightened by the length of this email - it's just wordy >explanations. > >After all this works, we can move on to implementing the Path >Effects tool and handle-dragging UI for editing effects on >canvas... that will be Stage III. > >Now, the goals in detail: > >1. Rename inkscape:distorted into inkscape:path-effect. This >attribute would store a string identifier of the effect to apply, >or "none". If there's no such attribute, it's the same as >"none". In addition, register several attributes for distortion >parameters: > >inkscape:path-effect-param1 >inkscape:path-effect-param2 >inkscape:path-effect-param3 > >etc. The interpretation of these will of course depend on the >value of inkscape:path-effect. > >Then, move the reading of these attributes into SPShape, as they >will be used by all its subclasses (not only SPPath but also >shapes) in the same way. (That is, sp_object_read_attr(object, >"inkscape:path-effect") etc must also be in sp_shape_build.) >Store the values in appropriate new members of SPShape. Write a >generic function that takes SPCurve and a SPShape pointers and >distorts the SPCurve according to the values of the members of >SPShape. Store that function in sp-shape.cpp and declare in >sp-shape.h so that it can be used from outside. > >You can even code a couple useful effects at this stage :) > >2. For SPPath, it's all ready: it reads original-d, distorts it >and sets the curve from that. In shapes, it's even simpler. Take >SPStar for an example. In sp-star.cpp, find the line > > sp_shape_set_curve_insync (SP_SHAPE (star), c, TRUE); > >and just insert the call to the distortion function in sp-shape >before that, passing it the curve and SP_SHAPE (star). That is >all! Shapes have no need for original-d because their path is >generated from the shape parameters anyway. > >3. Transforming objects works like this. In "preserve" mode (see >Inkscape Prefs), a transform= attribute is added or edited on all >transformed objects. In the "optimize" mode (which is the >default), various types of objects variously try to embed the >transform, or a component thereof. If this is not possible, again, >transform= attribute is added. For example, for paths, >sp_path_transform can completely embed all of the transform into >its curve (i.e. into d=), by transforming each path point by that >matrix, so it returns identity and transform= is not set. For >rects, sp_rect_set_transform embeds only translation and scaling >components of the matrix; the remainder, if any, is written as >transform=. For stars and ellipses, no embedding is attempted at >all, so the whole transform is always written as transform=. > >Now, for paths, sp_path_transform currently transforms the >(SPShape*)path->curve, i.e. the distorted curve stored in base >SPShape instance. But we also need to transform the original path >by the same matrix too, so that it stays in sync. The easiest way >to do this, which will also have other benefits, is to store the >original path in SPPath as another SPCurve. That is, >(SPShape*)path->curve will be the distorted path, while >(SPPath*)path->original_curve will store the original path. > >You will thus need to add this member in sp-path.h and to add to >store the original SPCurve before distortion in that member in >sp_path_set, case SP_ATTR_ORIGINAL_D. (You may need to figure out >how to copy SPCurves and/or bpaths. Also don't forget to free the >SPCurve when destroying the path in sp_path_release.) Then look at >sp_path_transform: > > /* Transform the path */ > NRBPath dpath, spath; > spath.path = shape->curve->bpath; > nr_path_duplicate_transform(&dpath, &spath, xform); > SPCurve *curve = sp_curve_new_from_bpath(dpath.path); > if (curve) { > sp_shape_set_curve(shape, curve, TRUE); > sp_curve_unref(curve); > } > >And just do the same also for your original SPCurve stored in >SPPath. That is all. > >For shapes, you normally don't need to do anything at all. Those >that don't attempt any embedding and always use transform= >attribute are not affected at all. Those that do embed do it just >by adjusting their internal shape parameters and regenerating the >curve - for example sp_rect_set_transform calls >sp_rect_set_shape(rect). Provided you inserted a distortion call >into *_set_shape, you are all set. > >CAVEAT: rects are the only shape which currently uses <rect>, not ><path>. So you cannot apply shape effects to rects at all, until >this is changed. It's on my TODO for a long time, hope I will get >a round tuit soon. > >4. The Inkscape::NodePath::Path reads the path from SPCurve, but >after modifying it, it writes directly to the d= attribute. This >needs to be changed thus: (a) if the path is distorted, read the >SPCurve from SPPath, not from SPShape (i.e. the original, not the >distorted one), and (b) if the path is distorted, write the edited >path to inkscape:original-d= instead of d= (in >update_repr_internal). Setting inkscape:original-d will trigger >reading it and setting both original and distorted curves, the >latter in turn triggering a redisplay of the distorted path. So I >think this will be enough for nodepath to edit the source path, >with the nodes generally not lying on the visible distorted >path. Adding a helper display of the original path between >nodepath nodes can be left for later. > >5. I think here nothing at all is needed. The knotholder thing >reads and writes from the shape's internal parameters, and thus is >totally unaffected by the visible distorted path. > >6. Look at sp_path_write: it writes the d= attribute from >(SPShape*)path->curve, that is, from the distorted path. So the >"same display in Batik" part is already taken care of. We only >need to write the original-d so it stays in sync. Just repeat this >block: > > if ( shape->curve != NULL ) { > NArtBpath *abp = sp_curve_first_bpath(shape->curve); > if (abp) { > gchar *str = sp_svg_write_path(abp); > sp_repr_set_attr(repr, "d", str); > g_free(str); > } else { > sp_repr_set_attr(repr, "d", ""); > } > } else { > sp_repr_set_attr(repr, "d", NULL); > } > >but for path->original_curve and the inkscape:original-d >attribute, and you are all set. > >For shapes, again, nothing needs to be done. Except for rects, >shapes' _write methods (e.g. sp_star_write) create <path> element >and set its d= from the SPShape curve. This is just what we need. > >That is all - as you see, it's all quite simple, logical and fits >neatly. There will be gotchas of course, but overall the system >looks quite straightforward and robust. I'm really excited by >this. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

path effects: our plan
by bulia byak 18 Mar '06

18 Mar '06

For those interested, below is the implementation plan for the live path effects that Aaron, Mental and I have developed. It's pretty simple and powerful, we just need more volunteers to work on it. It's currently in a branch in SVN. STAGE 1 is documented in a jabber chat from 2005-10-10. It is already implemented in the branch and seems to work fine (last time I checked, anyway). [19:01:50] <bbyak> well, i think the first thing you should do is familiarize yourself with SPCurve and Bpath classes [19:02:16] <bbyak> i guess for you they will be obvious, just another array of lineto/moveto/curvetos [19:04:00] <bbyak> then, write a simple spcurve->spcurve distortion function [19:04:09] <bbyak> any kind of distortion, just to check [19:04:52] <bbyak> make it a member of SPShape [19:05:26] <ACSpike> so the goal is to distort nartbpath [19:05:40] <bbyak> yes, as a start [19:05:52] <ACSpike> by way of spcurve [19:06:09] <ACSpike> and stick it in sp-shape [19:06:15] <bbyak> yes [19:06:16] <bbyak> then: [19:06:47] <bbyak> declare a bunch of attribs: inkscape:original-d and as many attrs as needed to express your distortion [19:06:50] <ACSpike> I don't understand how I will test this function [19:06:57] <bbyak> i'll explain that now [19:07:15] <bbyak> attribs are declared in attributes.h/cpp i think [19:07:33] <bbyak> then learn the way an SPObject reads attrs from the repr [19:07:36] <bbyak> it's simple: [19:07:52] <bbyak> for example sp-path.cpp [19:08:21] <bbyak> sp_path_build calls sp_object_read_attr for all attributes it knows [19:08:33] <bbyak> thoese calls end up in sp_path_set [19:09:01] <bbyak> which is where you do the necessary changes based on the attribute string passed to you [19:09:11] <bbyak> similar functions are in all other SPObjects [19:09:34] <ACSpike> "necessary changes" = distort path [19:09:40] <bbyak> we'll start by sp-path [19:09:41] <bbyak> yes [19:09:44] <bbyak> namely: [19:10:05] <bbyak> you'll need to add another member, a boolean flag in SPShape class [19:10:20] <bbyak> which if set means that this shape is distorted [19:10:42] <bbyak> and also you'll need one or more members for storing the distortion params [19:10:47] <ACSpike> oh, wife calls, brb. [19:11:16] <bbyak> then in sp_path_build you add another sp_object_read_attr for the distortion attribs [19:11:43] <bbyak> and in sp_path_set, a new case for those attrs [19:12:19] <bbyak> where you just parse and store the value in the (SPShape *) path, i.e. this path recast to shape [19:12:35] <bbyak> and set the "distorted" flag [19:13:02] <bbyak> those new sp_object_read_attr must go before the sp_object_read_attr for d= [19:13:30] <bbyak> then you add a sp_object_read_attr for inkscape:original-d [19:13:41] <bbyak> where you do the same as in case SP_ATTR_D: [19:13:58] <bbyak> but insert a call to the distortion function [19:14:12] <bbyak> after sp_svg_read_path(value); [19:14:32] <bbyak> then you set that distorted curve as usual, sp_shape_set_curve [19:14:47] <bbyak> and then one last thing: [19:15:41] <bbyak> the sp_object_read_attr for d= must go AFTER that for original-d, and in it, if the distorted flag is set, you simply skip reading the d and setting the curve [19:15:46] --- mental has left [19:16:08] <bbyak> so that the curve is obtained from orioginal-d with distortion, when they are present [19:16:47] <bbyak> that's all for stage 1, i think [19:17:10] <bbyak> it should work if you manually add the attrs to a path and it will show it distorted [19:17:19] <bbyak> and will be generally very instructive to play with [19:17:33] <bbyak> based on which, it will be more clear where to go next STAGE 2 is not done yet, I documented it in a message to Aaron: Overall, our Stage II goals are: 1. make the system capable of handling several different effects, with new ones easy to add 2. make sure effects are correctly read in SPPath and in all shapes 3. make sure objects with effects are correctly transformed 4. make sure paths with effects are correctly node-edited 5. make sure shapes with effects are correctly handle-edited 6. make sure objects with effects are correctly written and rendered the same in Batik Most of these goals are surprisingly easy to achieve :) So don't be frightened by the length of this email - it's just wordy explanations. After all this works, we can move on to implementing the Path Effects tool and handle-dragging UI for editing effects on canvas... that will be Stage III. Now, the goals in detail: 1. Rename inkscape:distorted into inkscape:path-effect. This attribute would store a string identifier of the effect to apply, or "none". If there's no such attribute, it's the same as "none". In addition, register several attributes for distortion parameters: inkscape:path-effect-param1 inkscape:path-effect-param2 inkscape:path-effect-param3 etc. The interpretation of these will of course depend on the value of inkscape:path-effect. Then, move the reading of these attributes into SPShape, as they will be used by all its subclasses (not only SPPath but also shapes) in the same way. (That is, sp_object_read_attr(object, "inkscape:path-effect") etc must also be in sp_shape_build.) Store the values in appropriate new members of SPShape. Write a generic function that takes SPCurve and a SPShape pointers and distorts the SPCurve according to the values of the members of SPShape. Store that function in sp-shape.cpp and declare in sp-shape.h so that it can be used from outside. You can even code a couple useful effects at this stage :) 2. For SPPath, it's all ready: it reads original-d, distorts it and sets the curve from that. In shapes, it's even simpler. Take SPStar for an example. In sp-star.cpp, find the line sp_shape_set_curve_insync (SP_SHAPE (star), c, TRUE); and just insert the call to the distortion function in sp-shape before that, passing it the curve and SP_SHAPE (star). That is all! Shapes have no need for original-d because their path is generated from the shape parameters anyway. 3. Transforming objects works like this. In "preserve" mode (see Inkscape Prefs), a transform= attribute is added or edited on all transformed objects. In the "optimize" mode (which is the default), various types of objects variously try to embed the transform, or a component thereof. If this is not possible, again, transform= attribute is added. For example, for paths, sp_path_transform can completely embed all of the transform into its curve (i.e. into d=), by transforming each path point by that matrix, so it returns identity and transform= is not set. For rects, sp_rect_set_transform embeds only translation and scaling components of the matrix; the remainder, if any, is written as transform=. For stars and ellipses, no embedding is attempted at all, so the whole transform is always written as transform=. Now, for paths, sp_path_transform currently transforms the (SPShape*)path->curve, i.e. the distorted curve stored in base SPShape instance. But we also need to transform the original path by the same matrix too, so that it stays in sync. The easiest way to do this, which will also have other benefits, is to store the original path in SPPath as another SPCurve. That is, (SPShape*)path->curve will be the distorted path, while (SPPath*)path->original_curve will store the original path. You will thus need to add this member in sp-path.h and to add to store the original SPCurve before distortion in that member in sp_path_set, case SP_ATTR_ORIGINAL_D. (You may need to figure out how to copy SPCurves and/or bpaths. Also don't forget to free the SPCurve when destroying the path in sp_path_release.) Then look at sp_path_transform: /* Transform the path */ NRBPath dpath, spath; spath.path = shape->curve->bpath; nr_path_duplicate_transform(&dpath, &spath, xform); SPCurve *curve = sp_curve_new_from_bpath(dpath.path); if (curve) { sp_shape_set_curve(shape, curve, TRUE); sp_curve_unref(curve); } And just do the same also for your original SPCurve stored in SPPath. That is all. For shapes, you normally don't need to do anything at all. Those that don't attempt any embedding and always use transform= attribute are not affected at all. Those that do embed do it just by adjusting their internal shape parameters and regenerating the curve - for example sp_rect_set_transform calls sp_rect_set_shape(rect). Provided you inserted a distortion call into *_set_shape, you are all set. CAVEAT: rects are the only shape which currently uses <rect>, not <path>. So you cannot apply shape effects to rects at all, until this is changed. It's on my TODO for a long time, hope I will get a round tuit soon. 4. The Inkscape::NodePath::Path reads the path from SPCurve, but after modifying it, it writes directly to the d= attribute. This needs to be changed thus: (a) if the path is distorted, read the SPCurve from SPPath, not from SPShape (i.e. the original, not the distorted one), and (b) if the path is distorted, write the edited path to inkscape:original-d= instead of d= (in update_repr_internal). Setting inkscape:original-d will trigger reading it and setting both original and distorted curves, the latter in turn triggering a redisplay of the distorted path. So I think this will be enough for nodepath to edit the source path, with the nodes generally not lying on the visible distorted path. Adding a helper display of the original path between nodepath nodes can be left for later. 5. I think here nothing at all is needed. The knotholder thing reads and writes from the shape's internal parameters, and thus is totally unaffected by the visible distorted path. 6. Look at sp_path_write: it writes the d= attribute from (SPShape*)path->curve, that is, from the distorted path. So the "same display in Batik" part is already taken care of. We only need to write the original-d so it stays in sync. Just repeat this block: if ( shape->curve != NULL ) { NArtBpath *abp = sp_curve_first_bpath(shape->curve); if (abp) { gchar *str = sp_svg_write_path(abp); sp_repr_set_attr(repr, "d", str); g_free(str); } else { sp_repr_set_attr(repr, "d", ""); } } else { sp_repr_set_attr(repr, "d", NULL); } but for path->original_curve and the inkscape:original-d attribute, and you are all set. For shapes, again, nothing needs to be done. Except for rects, shapes' _write methods (e.g. sp_star_write) create <path> element and set its d= from the SPShape curve. This is just what we need. That is all - as you see, it's all quite simple, logical and fits neatly. There will be gotchas of course, but overall the system looks quite straightforward and robust. I'm really excited by this. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by Martin Owens 18 Mar '06

18 Mar '06

Should you not want to have a permanent clipping option or ability so that the path is altered? Oh and could we please have the ability to clip a group of objects, I want to cut an object at a boundary line perhaps the page boundary I don't want to have to ungroup every object and clip each one, very annoying and causes alot of problems with very complex objects. On Sat, 18 Mar 2006 18:25:15 -0400 , "bulia byak" <buliabyak@...400...> wrote: >On 3/18/06, Andrius Ramanauskas <knutux@...400...> wrote: >> For the first case, I guess the simple approach would be to have something like: >> <defs> >> <clipPath id="clipPath123"> >> <use href="urlclipPathdefs> >> <g clip-path="#clipPath123"> >> ... the clipping object(s) ... >> ... the clipped objects ... >> </g> > >We might try that. But we'll need to code various special cases, such >as deleting the clippath and unclipping its users when the source of >the clone is deleted. Also various clone move compensations need to be >disabled for this case. > >However I have doubts about whether this will be convenient enough. I >think in a lot of cases, when I clip an object I do want the clippath >to disappear and not be in my way. If it stays visible, I will be >tempted to just delete it, which will remove or incapacitate the clip >- not the result I expected! I will therefore have to make it >invisible by removing fill and stroke, which is very inelegant and >brings lots of usability issues of its own. > >Also this approach, as well as Mental's, requires that clipped objects >are always grouped together with their clippers, which adds a layer of >indirection, its own special cases to guard against (what if I just >decide to ungroup it?), and usability issues. > >For these reasons, I feel more predisposed towards the other approach, >where the clipped object is just removed into defs and no grouping or >cloning is needed. It's much cleaner conceptually. Yes, it prevents >direct editing of the clippath unless you temporarily unclip it. But >enabling the node tool to edit the clippath without unclipping is >doable and relatively easy, and in any case this special-casing will >only affect the node tool and nothing else. So, I propose to do this >simple approach first, and then only if it proves inadequate, to look >into more complex solutions with cloning etc. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by bulia byak 18 Mar '06

18 Mar '06

On 3/18/06, Andrius Ramanauskas <knutux@...400...> wrote: > For the first case, I guess the simple approach would be to have something like: > <defs> > <clipPath id="clipPath123"> > <use href="url to the clipping object(s)> > </clipPath> > </defs> > <g clip-path="#clipPath123"> > ... the clipping object(s) ... > ... the clipped objects ... > </g> We might try that. But we'll need to code various special cases, such as deleting the clippath and unclipping its users when the source of the clone is deleted. Also various clone move compensations need to be disabled for this case. However I have doubts about whether this will be convenient enough. I think in a lot of cases, when I clip an object I do want the clippath to disappear and not be in my way. If it stays visible, I will be tempted to just delete it, which will remove or incapacitate the clip - not the result I expected! I will therefore have to make it invisible by removing fill and stroke, which is very inelegant and brings lots of usability issues of its own. Also this approach, as well as Mental's, requires that clipped objects are always grouped together with their clippers, which adds a layer of indirection, its own special cases to guard against (what if I just decide to ungroup it?), and usability issues. For these reasons, I feel more predisposed towards the other approach, where the clipped object is just removed into defs and no grouping or cloning is needed. It's much cleaner conceptually. Yes, it prevents direct editing of the clippath unless you temporarily unclip it. But enabling the node tool to edit the clippath without unclipping is doable and relatively easy, and in any case this special-casing will only affect the node tool and nothing else. So, I propose to do this simple approach first, and then only if it proves inadequate, to look into more complex solutions with cloning etc. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

We need SIOX!!!!
by unknown＠example.com 18 Mar '06

18 Mar '06

The SIOX demo was *very* interesting. http://www.siox.org/ It does fast foreground extraction from images based on color. Last night someone went and grabbed the source and hacked up initial support for this in Blender. We're already behind. :-) It looks like we might be able to gain some interesting benefits hooking that into tracing - perhaps potrace itself, or perhaps something additional. Oh, and it's also already in as a tool in the developer version of The GIMP.

1 0

Re: [Inkscape-devel] Clip path and mask UI patch - need guidance
by Andrius Ramanauskas 18 Mar '06

18 Mar '06

In my understandign there are two different cases: 1. mask/clippath object is leaved in the document 2. clipping object is moved into defs, but removed from document (no longer visible) For the first case, I guess the simple approach would be to have something like: <defs> <clipPath id="clipPath123"> <use href="url to the clipping object(s)> </clipPath> </defs> <g clip-path="#clipPath123"> ... the clipping object(s) ... ... the clipped objects ... </g> This leaves clippath in defs and allows edditing of a mask directly by editing a clipping object. This can also be implemented without a group and it should still work But for second scenario (object is removed) editing is more complicated, but we can still have this grouping and on entering (dbl-clicking) a group, clipping objects can be copied to a group, so they can be edited, after leaving a group copied object properties goes to a clipPath element and copied object is restored. Or a new manu item "Edit clip path" can be added, which will do basicly the same, but group will not be required, so this can also be used for masks created outside of Inkscape. Andrius On 3/18/06, bulia byak <buliabyak@...400...> wrote: > On 3/17/06, MenTaLguY <mental@...3...> wrote: > > If the clipPath and the clipped objects share a parent group, then you get "compensation" for free. > > Not entirely for free, and in any case no more free than when they are > elsewhere. Here's the scoop: The spec says that any transform= on > clipped object affects the clippath as well, and we implement this. > Therefore, for objects that always get transform= such as groups or > ellipses, you get transforming the clippath truly for free, and this > does not depend on where is the clippath - in defs or in group. It > works the same both ways. However for objects that completely or > partially embed the transformation, we will need to either (a) disable > that and write transform= if there's a clippath or mask, or (b) add > transform= to the clippath/mask corresponding to the embedded portion > of the transform. Both approaches are relatively easy to do. Your > approach (always putting clippend object(s) in group with clippath > there too) is just another way of doing the (a) - you just disable > embedding transforms into the object by virtue of its always being the > group. However for that you have to pay the price of an unavoidable > extra level of <g> and the dangers associated with > resources-not-in-defs which our legacy code is known to mishandle > often. > > > Unlike gradients, I don't see a strong case for re-using clipPaths either (another usual motivation for putting things in <defs>). > > Sure, I don't want them to be shared either. It's not about sharing or > not sharing. > > > Keeping the clipPath with the clipped objects seems to be the simplest approach... > > I don't think so, see above. Besides, if you rely on your clippaths > always inside groups and thus do not implement (a) or (b) above, you > will damage your ability to gracefully handle non-Inkscape SVGs. > > -- > bulia byak > Inkscape. Draw Freely. > http://www.inkscape.org > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

[Fwd: Inkscape und Xara Xtreme]
by Adib Taraben 18 Mar '06

18 Mar '06

Hello, I received an e-mail from the german computer magazin asking what is the progress with the XARA involvement and what is the impact/influence into Inkscape. And also he want to know if this is going into a competition between the two products. He is refering the LIBRE-Meeting. Was there someone? I did not really red all the e-mail's abaout that. So can someone summarize this? Thanks, Adib. -------- Original-Nachricht -------- Betreff: Inkscape und Xara Xtreme Datum: Fri, 17 Mar 2006 13:44:28 +0100 Von: Peter König <pek@...883...> An: Adib Taraben <taraben.a@...50...> Hallo, leider nur aus der Ferne verfolge ich das Libre Graphics Meeting in Lyon. Besonders interessiert mich die Entwicklung in Sachen Open Source Xara Xtreme und Inkscape. Nachdem Xara im vergangenen Jahr angekündigt hatte, den Code seiner Software für Linux und Mac freizugeben, kursierte meines Wissens nach die Vorstellung, dass die Communities von Xara und Inkscape eng zusammenarbeiten würden bzw. es eventuell sogar eine Fusion der Projekte geben würde. Mich würde interessieren, ob sich die Lage inzwischen verändert hat, und wie das Xara-Projekt bei Ihnen in der Inkscape-Community mittlerweile gesehen wird. Denn von Xaras Webseiten entnehme ich, dass die Firma großes vorhat: "Xara Xtreme on Linux will not only bring a leading-edge graphic tool to the platform, but with community assistance, has the potential to become the world's most powerful, easiest-to-use and simply the world's best graphics program." Auf den Veranstaltungsseiten des Libre Graphics Meeting heißt es noch etwas direkter: "Xara's goal is simple: With the help of the open-source developer community they hope to create the fastest, most powerful, easiest to use, general purpose graphics tool for Linux (and Mac)." Und das läuft doch in der Konsequenz auf eine direkte Konkurrenz zu Inkscape heraus, oder irre ich mich da? Über eine Einschätzung oder ein paar Hintergrundinformationen von Ihrer Seite würde ich mich freuen -- sie würden es mir ermöglichen, die Ankündigungen von Xara auf dem Libre Graphics Meeting etwas differenzierter in unserem Newsticker darzustellen. Können Sie mir da - zeitnah - weiterhelfen? Mit Dank und freundlichen Grüßen, Peter König c't - Magazin für Computertechnik http://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH & Co.KG phone: 0511-5352-763 Helstorfer Str. 7 fax: 0511-5352-417 D-30625 Hannover, Germany eMail: pek@...883...

4 4

Re: [Inkscape-devel] [Fwd: Inkscape und Xara Xtreme]
by Martin Owens 18 Mar '06

18 Mar '06

No I was just after potential benifits to inkscape of using their code. but Ben has filled in a few of those blanks. It would be good to see what converters they have, we still need that pdf lib. On Fri, 17 Mar 2006 20:16:40 +0300 , "Alexandre Prokoudine" <alexandre.prokoudine@...400...> wrote: >On 3/17/06, Martin Owens wrote: >> will we beable to use any of their code? > >Are you asking, whether we can reuse GPL code? :) > >Alexandre > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

release notes!!!
by bulia byak 18 Mar '06

18 Mar '06

Once again I urge all devs to promptly update the release notes: http://wiki.inkscape.org/wiki/index.php/ReleaseNotes If you procrastinate for too long, you may forget some important details, or even the very essense of your changes. As a result these changes will be underdescribed or completely omitted from this document, and as a result users will remain unaware of them. And _that_ means your changes will remain largely unnoticed, unused and UNTESTED. In extreme cases they will just bitrot and poison our codebase. Please don't let that happen. PLEASE review and update the document NOW. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

[Fwd: Your Exclusive Invitation to LinuxWorld ’s .Org Pavilion]
by Jon Phillips 17 Mar '06

17 Mar '06

I don't know which one of my involvements this person wanted involvement from, so I'm emailing all of my involvements to see if there is any interest in setting up a booth at LinuxWorld in San Francisco or Boston this year. LinuxWorld is mainly targeting Open Source business and not Open Source developers like Desktopcon/Ottawa Linux Symposium. Ping me back if there is interest in setting up a presence... Jon -------- Forwarded Message -------- > From: Alison_Dwelley@...1203... > To: jon@...235... > Subject: Your Exclusive Invitation to LinuxWorld ’s .Org Pavilion > Date: Tue, 7 Mar 2006 17:30:45 -0500 > > > Dear Jon, > > It is my pleasure to inform you that your organization has been chosen > for this year’s .Org Pavilion at the LinuxWorld Conference & Expo. > This invitation is for BOTH shows – Boston, April 3-6 and San > Francisco August 14-17, 2006. Please RSVP by March 10, 2006 to this > email or contact me via email at Alison_dwelley@...1204... If you can > only make one event please let me know at this time so that we can > make arrangements for another organization to take that place. > > The .org Pavilion is an exciting opportunity for .orgs to reach out to > the free software and open source communities during LinuxWorld > Conference & Expo. We are happy to provide this opportunity for you to > be recognized for all of your hard work in support of these > communities.If you are interested in participating please fax back the > contract(s) to 508-620-6690and we will send you additional > information. > > We are very excited to have you be a part of our 2006 .Org pavilion > and look forward to seeing you at both the Boston and San Francisco > LinuxWorld events. If you have any questions please do not hesitate > to contact me at 508-424-4834 or via email at Alison_dwelley@...1204... > > Kind Regards, > > Alison Dwelley > > > > > Alison Dwelley > Sales Operations Coordinator > IDG World Expo > Direct: 508-424-4834 > Fax: 508-620-6690 > alison_dwelley@...1203... > http://www.idgworldexpo.com -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)

8 7

Animation
by Martin Owens 17 Mar '06

17 Mar '06

Thinking about this feature, if inkscape wants to be a drawing tool then it will never develop the ability to handle animations, they would be counter to the way a document is handled, printed ect. but if inkscape is moving towards complete support of SVG only then it will be interesting to see animation features added, although I'd create a separate tool which used alot of the same code, because lets face it there is alot of really nice tools that can be developed for animation programs but aren't useful for a drawing app. -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

Re: [Inkscape-devel] layer dialog question
by MenTaLguY 17 Mar '06

17 Mar '06

On Fri, 17 Mar 2006 14:02:05 -0600, Aaron Spike <aaron@...749...> wrote: > I must have missed this... Why do you need both? Would the layers dialog > simply be a filtered special case of the object tree dialog? Not exactly. The layer dialog would be principally for working with layers as layers. A step up from the quick layer selector. Selecting a layer in the layer dialog would make it the current layer. The object tree dialog would be an expanded version of the XML editor. There, selection would mean selection as an object, and you'd have an attributes pane, etc... We'd probably be able to reuse the same widget for the tree portion of both dialogs, but that's about all they'd have in common. -mental

1 0

layer dialog question
by MenTaLguY 17 Mar '06

17 Mar '06

Should the layer dialog show only the "normal" layers, or show also groups which have been temporarily promoted into layers as the quick layer selector does? -mental

4 8

Re: [Inkscape-devel] layer dialog question
by Martin Owens 17 Mar '06

17 Mar '06

It'd be nice to treat linked svg like a sub layer too. On Fri, 17 Mar 2006 12:03:48 -0700 , "Joshua A. Andler" <joshua@...533...> wrote: >mental@...3... wrote: >> Quoting bulia byak <buliabyak@...400...>: >> >> >>> I remember you were talking about it showing even down to >>> individual objects if you expand the tree. >>> >> >> I'm leaning away from that now after our last conversation on the >> topic (some time ago). Among other things, selection of layers >> (sets the current layer) is very different to selection of objects >> (selects objects). >> >> I think what I want to do at this point is to do a traditional >> layers dialog that just does layer-ish stuff, and then rework the >> XML dialog to provide both "XML" and "SVG Object" views. >> > > >I just wanted to follow-up on this as I had been doing some print work >in Illustrator this morning and checked their layers dialog. As of at >least AI 10 you can expand the layers down to groups and groups down to >objects, etc (and of course continue expanding groups if there are more >nested in there). I know we don't follow Illustrator by any means, but >the more I think about it, it does make sense to expand down that far in >the layers dialog. I think it makes more sense since we are now going to >have to work with sub-layers in that dialog anyway (which will already >require a tree view since there is now UI to create sub-layers). Just an >updated .02 ;) > >-Josh > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

Re: [Inkscape-devel] [Fwd: Inkscape und Xara Xtreme]
by Martin Owens 17 Mar '06

17 Mar '06

will we beable to use any of their code? On Fri, 17 Mar 2006 15:47:15 +0100 , Adib Taraben <taraben.a@...50...> wrote: >Hello, > >I received an e-mail from the german computer magazin asking what is the >progress with the XARA involvement and what is the impact/influence into >Inkscape. >And also he want to know if this is going into a competition between the >two products. >He is refering the LIBRE-Meeting. Was there someone? > >I did not really red all the e-mail's abaout that. So can someone >summarize this? > >Thanks, > >Adib. >-------- Original-Nachricht -------- >Betreff: Inkscape und Xara Xtreme >Datum: Fri, 17 Mar 2006 13:44:28 +0100 >Von: Peter König <pek@...883...> >An: Adib Taraben <taraben.a@...50...> > >Hallo, > >leider nur aus der Ferne verfolge ich das Libre Graphics Meeting in >Lyon. Besonders interessiert mich die Entwicklung in Sachen Open Source >Xara Xtreme und Inkscape. > >Nachdem Xara im vergangenen Jahr angekündigt hatte, den Code seiner >Software für Linux und Mac freizugeben, kursierte meines Wissens nach >die Vorstellung, dass die Communities von Xara und Inkscape eng >zusammenarbeiten würden bzw. es eventuell sogar eine Fusion der Projekte >geben würde. > >Mich würde interessieren, ob sich die Lage inzwischen verändert hat, und >wie das Xara-Projekt bei Ihnen in der Inkscape-Community mittlerweile >gesehen wird. Denn von Xaras Webseiten entnehme ich, dass die Firma >großes vorhat: > >"Xara Xtreme on Linux will not only bring a leading-edge graphic tool to >the platform, but with community assistance, has the potential to become >the world's most powerful, easiest-to-use and simply the world's best >graphics program." > >Auf den Veranstaltungsseiten des Libre Graphics Meeting heißt es noch >etwas direkter: > >"Xara's goal is simple: With the help of the open-source developer >community they hope to create the fastest, most powerful, easiest to >use, general purpose graphics tool for Linux (and Mac)." > >Und das läuft doch in der Konsequenz auf eine direkte Konkurrenz zu >Inkscape heraus, oder irre ich mich da? Über eine Einschätzung oder ein >paar Hintergrundinformationen von Ihrer Seite würde ich mich freuen -- >sie würden es mir ermöglichen, die Ankündigungen von Xara auf dem Libre >Graphics Meeting etwas differenzierter in unserem Newsticker darzustellen. > >Können Sie mir da - zeitnah - weiterhelfen? > >Mit Dank und freundlichen Grüßen, > >Peter König > >c't - Magazin für Computertechnik http://www.heise.de/ct/ >Heise Zeitschriften Verlag GmbH & Co.KG phone: 0511-5352-763 >Helstorfer Str. 7 fax: 0511-5352-417 >D-30625 Hannover, Germany eMail: pek@...883... > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

[Fwd: Getting Inkscape working on my iBook G4]
by Jon Phillips 17 Mar '06

17 Mar '06

Hi David, I've forwarded your request to the Inkscape development and user mailing lists. If anyone else knows the problem, please contribute. Thanks, Jon -------- Forwarded Message -------- > From: rejon.org feedback form <noreply@...235...> > Reply-To: jon@...235... > To: jon@...235... > Subject: Getting Inkscape working on my iBook G4 > Date: Tue, 14 Mar 2006 05:11:30 -0600 > > Name: David Karner > E-mail: davekarner@...1210... > > > Hello, > > I've installed my first copy of Inkscape but I can't seem to get past > the "Apple X11 Required, Please install and restart Inkscape" stage. > I installed X11 from my Tiger Installation CD and thought that would > do it. I restarted Inkscape, but still received the error. > > Do you know what step I'm missing? > > I would appreciate any support you could give me in getting going > with Inkscape! > > Sincerely, > > David > > -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897... Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) Creative Commons (www.creativecommons.org) San Francisco Art Institute (www.sfai.edu)

3 2

WEBFORM problems downloading _20060306.dmg (OSX)
by Kat 17 Mar '06

17 Mar '06

Message from Inkscape submission form Please note, that the submitter may not read this list. CC your answer to the submitter name: Kat email: kat888@...65... submitted the following: Hi, I\'m having problems downloading Inkscape_20060306.dmg (Which I\'m hoping will work with OSX 10.4.5) - gets to about 3.5M and then the download stalls. Is there an alternative source? The only others I have found have v0.43-2 which won\'t work with the updated X11 environment in 10.4.5. Thanks Kat

2 1

crispy icons?
by bulia byak 17 Mar '06

17 Mar '06

Have we switched to the crispy set by now? If not, what holds us back? If nothing, can anyone please do this? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 3

"link" and "unlink" in icons
by Aaron Spike 16 Mar '06

16 Mar '06

In our three icons sets we have three different depictions of link and unlink for edit_clone and edit_unlink_clone. The legacy set features a yellow line. The new crispy set features a padlock. And David's set features a chain. I prefer the chain. It means something to me. When I see the chain I immediately think about "link". For me this is a better iconification of the concept. Is this a cultural issue? Would anyone else prefer the chain over the lock? Perhaps icon sets need to be localized. :-) Aaron Spike

3 2

Fwd: Message sent to Toyo Inks Melbourne
by Janet Hawtin 16 Mar '06

16 Mar '06

Hi team I am not a dev person, but I posted to a company today that I thought could be a good potential partner for opensource graphic application developers. The are an international printing ink manufacturer. Much respected in the printing sector and who do have an alternative colour matching system integrated into proprietory software at this time. As they are not the primary colour matching system used in that market I thought they might be interested in what could happen if they partner with open source tech. Anyway my 2 messages are included below in reverse order. Top one is to Kylie in Melbourne, Bottom one was sent first, through their website form. I am trying to make sure that I am letting the developers know what I posted. These messages were posted by me as an individual and are not intended to represent the opinion of any group, but I hope that they will make it possible for Toyo to check out open source and see if its something they can participate in. All the best Janet -------- Original Message -------- Subject: Libre Graphics Meeting, 17, 18 and 19 March 2006 in Lyon, France Date: Thu, 16 Mar 2006 16:43:06 +1030 From: Janet Hawtin <lucychili@...1211...> Reply-To: lucychili@...1211... To: reception@...1212... Kylie Following up from the phonecall this afternoon: Possible opportunity for Toyo Inks with open source software. A colour matching system such as colourfinder, if open sourced, could be included in this emerging sector of software. http://www.toyoink.com/products/colorfinder.asp Toyo has top quality ink and so this could be a way to get designers using the full gamut of your colour range as they would be specifying using your swatches and colour matching system. Here is the link to the event where open source developers and graphic designers from around the world will be meeting in France: http://www.libregraphicsmeeting.org/ The first Libre Graphics Meeting will be held on 17, 18 and 19 March 2006 in Lyon, France in the Ecole d'Ingénieurs CPE on the university campus at La Doua, Villeurbanne. Here is a copy of the message that I sent to Toyo Japan: Dear Toyo Inks I am a graphic designer who is making the shift from proprietory software to open source software. One of the challenges faced by the developers of open source software is that Pantone colour matching is proprietory and so can not be integrated into open source software. I remembered getting a swatch set of your inks, the colours were lovely and thought I would contact you to see if you would be interested in becoming the open source community's default colour matching group. I know the Free Software Foundation is very active in Japan, and I am sure that in the long run this could provide and exciting opportunity both for open source software such as Gimp and InkScape as well as for Toyo inks as they become the ink colour that people specify in their artwork. Hope this idea is useful. All the best. Janet

1 0

Re: [Inkscape-devel] "link" and "unlink" in icons
by Martin Owens 16 Mar '06

16 Mar '06

This is not a cultural thing but a language thing. 1) Chains have links, you are not showing a chain but a link in a chain 2) Padlocks mean something else, they are to protect, keep out and to lock The padlock could mean 'don't let me change this object keep it padlocked' where as the chain link would mean 'I want to link like a chain' I don't know what other languages and cultures would use but we've never had problems enforcing our own ideas of symbolism on the rest of the world why stop now. Best Regards, Martin Owens On Wed, 15 Mar 2006 18:45:24 -0400 , "bulia byak" <buliabyak@...400...> wrote: >On 3/15/06, Aaron Spike <aaron@...749...> wrote: >> In our three icons sets we have three different depictions of link and >> unlink for edit_clone and edit_unlink_clone. The legacy set features a >> yellow line. The new crispy set features a padlock. And David's set >> features a chain. > >Hmm, I think I like the chain better, too. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

Wiki unusable
by Ralf Stephan 15 Mar '06

15 Mar '06

Hello, the Wiki is unusable atm, 30 sec for one page! Can someone please have a look at this? ralf

3 2

Icons
by Joshua A. Andler 15 Mar '06

15 Mar '06

I'm in the process of replacing the icons... unfortunately tortoise svn spazzed after I renamed the old set, and I'm having to do a clean check out to get it resolved. It should be done shortly. Thanks for your patience!

1 1

Help with style setting
by Jon A. Cruz 14 Mar '06

14 Mar '06

Help. Tricky code and lack of sleep have slowed my brain a bit too much. For doing color drag-n-drop I've got an SPItem pointer, and the color RGB value that was that was dropped onto it. My main question is what is the 'proper' way to do that?

3 8

linux compile error with gc
by Patrick Shirkey 13 Mar '06

13 Mar '06

Hi, I am getting this compile error with inkscape on linux. I have installed gc2.7 and was using gc2.5 before that with no difference. ------- gc.cpp:118: error: `GC_enable' was not declared in this scope gc.cpp:119: error: `GC_disable' was not declared in this scope gc.cpp:136: error: `GC_enable' was not declared in this scope gc.cpp:137: error: `GC_disable' was not declared in this scope make[2]: *** [gc.o] Error 1 make[2]: Leaving directory `/usr/local/src/inkscape-0.43/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/inkscape-0.43' make: *** [all] Error 2 ------- -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== Apparently upon the beginning of the barrage, the donkey broke discipline and panicked, toppling the cart. At that point, the rockets disconnected from the timer, leaving them strewn around the street. Tethered to the now toppled cart, the donkey was unable to escape before the arrival of U.S. troops. United Press International Rockets on donkeys hit major Baghdad sites By P. MITCHELL PROTHERO Published 11/21/2003 11:13 AM

2 2