- Inkscape Devel - Inkscape Mailman

round corners won't be resized on resizing a object
by Frank Wunderlich 21 Mar '06

21 Mar '06

Hi, i try to explain the behavior: i have 2 rects: 1 rect with round corners and 1 rect with normal corners inside the first one if i group this 2 shapes and try to make this group smaller, the shape is correctly resized (both rects), but not the corners of the round rect. the radius of the corners must be also adjusted... Greetings Frank

2 1

Clip path and mask UI patch - need guidance
by Joshua A. Andler 21 Mar '06

21 Mar '06

Knutux has made excellent progress with the clipPath/Mask UI patch (nice couple options in prefs to make it more robust too). However, there are two issues left that are related, but we couldn't figure out the best solution. Note that this is in comparison to both Xara & Illustrator as reference. 1) In Inkscape, currently you can not edit a clippath on canvas (presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem. 2) In Xara or Illustrator when you clip objects, they're "grouped" together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc. The more complicated of the two issues would be number 2. We kicked around a couple ideas, but neither seemed like the optimal solution so I figure I would ask for advice here. The ideas were having the clipping object in defs be a clone of a "normal" object on canvas. That original object can then be grouped and the clone/clippath would follow a move of the original, and it would theoretically also take care of the editing aspect too. And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas. Again, that object could then be grouped and would take care of the editing aspect too. To me, neither method seems clean and each would potentially introduce it's own set of issues. Bulia or Mental, do you have any suggestions? -Josh

5 19

Bug in the command line interface of Inkscape on Windows 32 platform ?
by Gilles Foucault 21 Mar '06

21 Mar '06

I run the Inkscape 0.43+devel, built Mar 20 2006 on Windows 32 platform I would like to export svg files via the command line interface of Inkscape : "C:\Program Files\Inkscape\inkscape.exe" --export-eps=out.eps in.svg But nothing happens, there is no error messages, and inkscape quit immediately. Could you help me with the command line usage in Win32 platform ? Thanks in advance, Best regards Gilles

2 1

LGM braindump
by Jon A. Cruz 21 Mar '06

21 Mar '06

Here's the first bit of braindump from LGM. (Please keep in mind that I typed this up while flying back to the States, and am not sure how jetlagged I was) -------------------------------- Overall, I think the whole get-together was an amazing success. Many different projects were represented, and a fair mix of end users and potential contributers were also in attendance. Although I would like to see more of the users and just curious there, enough were present to help give a good insight with fresh perspective. There were perhaps up to a couple hundred people in attendance, and it clearly seemed to be even a better turn out than Bryce or I had expected. We had four people with "Inkscape" on their badges, with a few extra people here and there like Cedric. The GIMP had a good presence, as did Scribus and even Xara. The atmosphere was one of the really good aspects of the whole meeting. Unlike many other conferences, this was not just a one-way dispersal of information. Though the presentations were similar, afterwards there was a lot of interaction between people with different groups, and even and users. Also, there seemed to not be any real conflicts or posturing, but rather a lot of genuine collaboration going on with win-win situations popping up all over. Probably the best illustration of this was with the SIOX presentation. Part of the presentation's purpose was to get the word out about the capabilities, and to try to spur more interest. That night one of the Blender guys got hooked, and by the next day had hacked together basic support for SIOX as a standard Blender effect. Each of the teams took advantage of the face-to-face time to have their own group meetings. For example, this was the first time that Craig had actually gotten to actually meet the other people on Scribus. But there was also a lot of communication with people of different groups, and most of the hitting dinner, etc, was completely inclusive. I know that some of the GIMP people expressed a little regret at not being able to get together with some of the non-GIMP people as much as they'd like, but this was only due to being able to get so much done in the various GIMP sit-downs going on. Even so, there was quite a lot that did get done, with various people in different groups each talking with others about all sorts of things. Xara had a booth outside the main amphitheater, and had three people showing what they've been doing. As you probably already know, they took the opportunity to release their source-code, and it seems like the delay 'till now was time well spent. I know that Carl Worth mentioned he downloaded it and not only did it build first try for him, but it actually ran too. The funny thing was that he didn't realize how much progress had been made since the initial demo, and that most of the tools are functional now. Their developers seemed like really good people, and very interested in the whole meeting and everything going on. I'd also met them on the bus from the airport the night before. So there was time spent talking with them on various Xara stuff, but then also a lot of time talking about all the other things going on, the stuff the other developers were talking about, and also some more questions on how best to fit in with the general open-source community. Charles from Xara made it down on Sunday, and after his presentation we had the opportunity to all sit down with him and discuss various Inkscape-Xara issues. The great news is that he honestly seems to "get it", and is working well to try to ensure the release of Xara has the best chance of being a win-win both for the business aspect and for the open-source community. By the end of things it was very clear that both Xara and Inkscape had their own focus, and each has their own reason for being around for quite some time. Probably the main issue for some will be the contributors agreement, however as everyone had time to drill down on things, and also others like Carl Worth from Cairo, it seemed to be a fair approach and my personal feeling is that it won't be a deal-killer for most. Speaking of Carl, he also had time to meet with Charles on his own, and they came away with quite a lot resolved, and a strong interest to see where things will go from here. Among other things, they were looking at various ways that Xara might get things to have Cairo to use their engine, so it will be *very* interesting to see how things progress in that area. One surprisingly inspiring presentation was Marti's talk on color management and littleCMS. Even though I'd been familiar with the concepts, and even had drilled down on littleCMS's API to figure out how to hook it into Inkscape, the talk suddenly made all the pieces fall into place. More importantly, it did so with several groups, and after the talk there was a lot started between us and Scribus in regards to managed color-flow, and we realized that together we actually almost at the point of having base things there and integrated. A lot of stuff they had been doing had gotten them close, and lot of the stuff I'd been doing had gotten us close. Then again, Marti confirmed that for basic support, only three functions of the littleCMS API are needed, so we might see that go in *very* soon. Additionally, we were able to use this to help hammer out with Scribus what direction they might want to take on SVG vs. EPS import, and whether things should be done in Inkscape or in Scribus, and to what degree. We probably ended up changing some minds and getting their focus back on enhancing SVG import, since we figured out some basic ways to support spot colors along with full ICC-profile targeted colors in SVG we will end up putting out. And, of course, Marti will be able to help advise us on the proper approach for a lot of the SVG/CSS color-profile details. One of the Inkscape-specific things that came up was someone from Slovenia being interested in animation support. We discussed quite a few things, including some general ideas of what Inkscape should and should not do in regards to UI and feature support for animation that Andy, Bryce, and I had just been tossing around the day before. This also leverages a bit more resources for enhancing the extensions mechanism, so look for new people to possibly show up soon. Speaking of extensions and plugins... there was a lot of general interest in this from many different people, with many different priorities. One of the more interesting exchanges on this was between myself and Craig from scribus. After some Scribus demos it had come up to me that what we were thinking of might be helpful for them also. Craig got really excited about the main idea of exposing a DOM for plugins, and some of the ways that they might go about doing that. Then we moved on to my ideas for abstracting UI for plugins by using XForms. He hadn't been aware of it before (and in fact was very light on XML background in general) but as I drilled in on more and more details he came to feel that it was a very good approach, and cold solve quite a few of the problems they are hitting up against right now, and even more in the future. He also mentioned this might be a concept to push over to the Xara guys (he'd been spending a fair bit of time with them also). One of the last things to go on was a CREATE BOF. It followed our Inkscape BOF, and ended up being very productive. We had lots of people from many projects, and got some good issues hammered out. Watch for more details on the CREATE mailing list, but a lot was about shared assets like palettes, brushes, etc., ways to share them, and how to make that work well (directories, daemons, things like font mangers, etc.) and not lagging. Another aspect was brought up from the drag-n-drop stuff I've been working on lately. Aside from knowing what to share, we also need to come up with how to put those things properly on the clipboard and for drag-n-drop. One point brought up was that it might be good to work details up and then leverage freedesktop.org to actually get MIME types registered. I'll follow up with more, like how Andy's demo went (great), Pippin's impressive stuff, and ReJon's great talk...

1 0

extension attributes documentation
by MenTaLguY 21 Mar '06

21 Mar '06

Hi all, In an effort to get the ball rolling for documenting Inkscape's extension attributes, I've populated a wiki entry with them here: http://wiki.inkscape.org/wiki/index.php/ExtensionAttributes I'd encourage volunteers to have a look and add documentation (just a brief description to start with) for any attributes that interest them. -mental

2 1

Clip path and mask UI patch - committed
by bulia byak 20 Mar '06

20 Mar '06

I have committed Andrius' patch and a couple of fixes of my own. So, clipping and masking are almost usable now. Use and abuse them, and report the results. So far the UI is limited to 4 command in the Object menu. Of course there are lots of issues, this is to be expected; note that while we appreciate your suggestions for how to make the UI better, for now my personal priority is to iron out all the basic behavior and rendering issues, so that at least the UI that we have works flawlessly. Several immediate issues are: - After you moved the clipped/masked object, unclipping/unmasking gives a wrong transform to the clippath/mask. - Mask display is buggy. If you don't see the masked object, try zooming in or out. - Upon unclpping/unmasking, the selection must hold the clipped object and the clippath/mask. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 2

Xara source released
by Joshua A. Andler 19 Mar '06

19 Mar '06

Subject line says it all... http://www.xaraxtreme.org/developers/sourcecode.html Thanks for the heads up John :) -Josh

6 6

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