Losing colours when copying
I am using some images from openclipart.
I am trying to copy two different balloons (clipart/recreation/party/balloon-red-aj.svg and balloon-blue-aj.svg) into a single new image.
I first copy -red and paste into the new image and all is good. When I copy -blue and paste into the new image, it is pasted also as red (not blue). Nothing I seem to do will copy the image over as blue.
If I create a second new image and paste just the blue, it copies over as blue. If I then copy red and paste, it pastes as blue.
Any suggestions as to how I can get the copy to happen?
Thanks, mG.
On 11/10/2007, at 10:22 AM, greg fenton wrote:
I am using some images from openclipart.
I am trying to copy two different balloons (clipart/recreation/ party/balloon-red-aj.svg and balloon-blue-aj.svg) into a single new image.
I first copy -red and paste into the new image and all is good. When I copy -blue and paste into the new image, it is pasted also as red (not blue). Nothing I seem to do will copy the image over as blue.
If I create a second new image and paste just the blue, it copies over as blue. If I then copy red and paste, it pastes as blue.
Any suggestions as to how I can get the copy to happen?
Just a guess...
I had an SVG file where some of the colour were defined using CSS as a top-level style tag. When they were opened in Inkscape they displayed fine, but those colour came out wrong when copied to a new file since I guess the CSS values were not copied across.
I was able to paste it to the other file with correct colours by: 1) Open the file in Inkscape 2) Select the relevant objects and copy 3) Paste them within the same document 4) Copy the newly pasted selection 5) Paste that into the new document
These steps don't work with you balloon example. Your problem looks similar but with gradients instead of CSS, probably because the gradients are named the same in different coloured balloon images, so the pasted blue balloon just references the red balloons gradients in the pasted version since they are named the same.
I'm not sure if this should be considered a bug or not (multiple pasted balloons use the same gradients). CC'ing to the developers list to see what people think about this, and whether there is any kind of hidden option to get the behaviour you want.
Cheers, Michael
On 10/10/07, Michael Wybrow <michael.wybrow@...131...> wrote:
the gradients are named the same in different coloured balloon images, so the pasted blue balloon just references the red balloons gradients in the pasted version since they are named the same.
I'm not sure if this should be considered a bug or not (multiple pasted balloons use the same gradients).
Michael,
Your suggestion was right. I used VIM and did:
:%s@(["#])(linear|radial)Gradient@\1\2GradientRed@...2363...
for the red file, ...GradientBlue for the blue file and ...GradientYellow for the yellow file.
I was then able to copy and paste from each of those files into a new file and not lose their colours.
So the way I see it is a feature request:
FEATURE: when copying from one image to another with same-named style attributes, have the option to rename those styles (especially if the definition of same-named styles differ between buffers).
[Thanks too ACSpike on #inkscape!!]
Thanks! mG.
I also consider this a major shortcoming in Inkscape, to be honest. I want to copy and paste a lot between Inkscape documents, but if the colors of the pasted objects change it is no use. Thanks a lot for your suggestion! Now I need to find something similar in Windows...
________________________________
From: inkscape-user-bounces@lists.sourceforge.net [mailto:inkscape-user-bounces@lists.sourceforge.net] On Behalf Of greg fenton Sent: 11. oktober 2007 04:31 To: Inkscape User Community Cc: Inkscape List Devel Subject: Re: [Inkscape-user] Losing colours when copying
On 10/10/07, Michael Wybrow <michael.wybrow@...131... > wrote:
the gradients are named the same in different coloured balloon images, so the pasted blue balloon just references the red balloons gradients in the pasted version since they are named the same.
I'm not sure if this should be considered a bug or not (multiple pasted balloons use the same gradients).
Michael,
Your suggestion was right. I used VIM and did:
:%s@(["#])(linear|radial)Gradient@\1\2GradientRed@...2363...
for the red file, ...GradientBlue for the blue file and ...GradientYellow for the yellow file.
I was then able to copy and paste from each of those files into a new file and not lose their colours.
So the way I see it is a feature request:
FEATURE: when copying from one image to another with same-named style attributes, have the option to rename those styles (especially if the definition of same-named styles differ between buffers).
[Thanks too ACSpike on #inkscape!!]
Thanks! mG.
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no **********************************************************************
On 10/11/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
I also consider this a major shortcoming in Inkscape, to be honest. I want to copy and paste a lot between Inkscape documents, but if the colors of the pasted objects change it is no use. Thanks a lot for your suggestion! Now I need to find something similar in Windows...
VIM works quite well on MS-Windows:
http://www.vim.org/download.php#pc
Though any text editor worth its muster should be capable of regular expression search and replace.
mG.
Indeed. But it would be nice to do it as a batch-process. Although, thinking of it, Notepad++ can open several files at once and perform a "search and replace" on all open files. That's almost batch.
This forum is a great place for thinking aloud :D
________________________________
From: inkscape-user-bounces@lists.sourceforge.net [mailto:inkscape-user-bounces@lists.sourceforge.net] On Behalf Of greg fenton Sent: 11. oktober 2007 15:41 To: Inkscape User Community Subject: Re: [Inkscape-user] Losing colours when copying
On 10/11/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
I also consider this a major shortcoming in Inkscape, to be honest. I want to copy and paste a lot between Inkscape documents, but if the colors of the pasted objects change it is no use. Thanks a lot for your suggestion! Now I need to find something similar in Windows...
VIM works quite well on MS-Windows:
http://www.vim.org/download.php#pc
Though any text editor worth its muster should be capable of regular expression search and replace.
mG.
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no **********************************************************************
On 10/11/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Indeed. But it would be nice to do it as a batch-process. Although, thinking of it, Notepad++ can open several files at once and perform a "search and replace" on all open files. That's almost batch.
Yes, but can the replace string be a function of the filename?
Alternatively, a Perl script could do it quite handily.
mG.
On Thursday, October 11, 2007, 3:33:30 AM, Michael wrote:
MW> I had an SVG file where some of the colour were defined using CSS MW> as a top-level style tag. When they were opened in Inkscape they MW> displayed fine, but those colour came out wrong when copied to a MW> new file since I guess the CSS values were not copied across.
Or because the styles are mixed together.
I suspect the two balloon cliparts are the same structure with different styling. (This is another area where presentation attributes give you a benefit, since that mixing will not hapen).
MW> I was able to paste it to the other file with correct colours by: MW> 1) Open the file in Inkscape MW> 2) Select the relevant objects and copy MW> 3) Paste them within the same document MW> 4) Copy the newly pasted selection MW> 5) Paste that into the new document
MW> These steps don't work with you balloon example. Your problem MW> looks similar but with gradients instead of CSS,
Gradients us a styling property, in SVG. So its quite likely to be the same thing. Or conflicting ids (two gradients, with different colors, with the same id).
MW> probably because MW> the gradients are named the same in different coloured balloon MW> images, so the pasted blue balloon just references the red MW> balloons gradients in the pasted version since they are named the same.
Yes I think thats the case here. In which case it can be fixed up in a text editor using search and replace.
MW> I'm not sure if this should be considered a bug or not (multiple MW> pasted balloons use the same gradients). MW> CC'ing to the developers list to see what people think about MW> this, and whether there is any kind of hidden option to get the behaviour you want.
Not detecting duplicate ids could be considered a bug. Of course by the time the second balloon is pasted in, its too late to disambiguate the references. However, detecting a potential id conflict between the current document and the copy/paste buffer when paste is selected (and warning, offering to fix up the conflicts before pasting) would be a nice feature.
On 10/11/07, Chris Lilley <chris@...214...> wrote:
Not detecting duplicate ids could be considered a bug.
And it is in fact one of the oldest bugs in our tracker. Mental has some grand plan for fixing it, which is one reason why I haven't yet tried a simpler hack :)
I'm just wondering why it happens? Are the names for the gradients assigned based on a incrementing counter? Can't we just assign them random numbers?
-----Original Message----- From: inkscape-user-bounces@lists.sourceforge.net [mailto:inkscape-user-bounces@lists.sourceforge.net] On Behalf Of bulia byak Sent: 11. oktober 2007 17:05 To: Chris Lilley; MenTaLguY Cc: Michael Wybrow; Inkscape List Devel; Inkscape User Community Subject: Re: [Inkscape-user] [Inkscape-devel] Losing colours when copying
On 10/11/07, Chris Lilley <chris@...214...> wrote:
Not detecting duplicate ids could be considered a bug.
And it is in fact one of the oldest bugs in our tracker. Mental has some grand plan for fixing it, which is one reason why I haven't yet tried a simpler hack :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no **********************************************************************
On 10/11/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
I'm just wondering why it happens? Are the names for the gradients assigned based on a incrementing counter? Can't we just assign them random numbers?
This will only diminish the problem but not eliminate it. Collisions will still be possible, and old documents will not be fixed (randomized) by this and will still collide.
I've made a program for creating slides using Inkscape:
http://wiki.inkscape.org/wiki/index.php/InkSlide
...of course I discovered the existing one in the same place when I went to post it there, but mine does much more of the work for you.
It's currently very slow because it uses --query-height etc. many times per slide. I filed a RFE
https://sourceforge.net/tracker/index.php?func=detail&aid=1811901&gr...
but I think I could code this into main.cpp well enough myself... if I do that and submit a patch will it probably make it in, or would it be better for someone more familiar with the code base to do it in a way that's more in keeping with other code - assuming that anyone thinks it's worthwhile, and also assuming my patch might be greeted with "why on earth would you do it that way!?" ;-)
Cheers -Terry
Looks cool, have you thought about using rST [0] for the markup? There's already a tool to convert rst to s5[1] slideshows, but it would be cool to have another slideshow backend for it.
matt
[0] http://docutils.sourceforge.net/rst.html [1] http://meyerweb.com/eric/tools/s5/
On 10/17/07, Terry Brown <terry_n_brown@...12...> wrote:
I've made a program for creating slides using Inkscape:
http://wiki.inkscape.org/wiki/index.php/InkSlide
...of course I discovered the existing one in the same place when I went to post it there, but mine does much more of the work for you.
It's currently very slow because it uses --query-height etc. many times per slide. I filed a RFE
https://sourceforge.net/tracker/index.php?func=detail&aid=1811901&gr...
but I think I could code this into main.cpp well enough myself... if I do that and submit a patch will it probably make it in, or would it be better for someone more familiar with the code base to do it in a way that's more in keeping with other code - assuming that anyone thinks it's worthwhile, and also assuming my patch might be greeted with "why on earth would you do it that way!?" ;-)
Cheers -Terry
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 10/17/07, Terry Brown <terry_n_brown@...12...> wrote:
It's currently very slow because it uses --query-height etc. many times per slide. I filed a RFE
https://sourceforge.net/tracker/index.php?func=detail&aid=1811901&gr...
but I think I could code this into main.cpp well enough myself... if I do that and submit a patch will it probably make it in, or would it be better for someone more familiar with the code base to do it in a way that's more in keeping with other code - assuming that anyone thinks it's worthwhile, and also assuming my patch might be greeted with "why on earth would you do it that way!?" ;-)
Yes, I think such a patch will be welcome. I just think we need to spend some more time designing the output format of such an option, so that it:
1 is easy to understand for a human even without reading documentation
2 is easy to parse by scripts
3 is easy to extend in the future, to provide more info about objects, without breaking backwards compatibility
Your suggestion in the RFE is good on 2, but worse on 1, and I'm not sure about 3. What do you think?
Hey people,
Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke to fill, break fill apart and remove the inner path. Is there an easier way?
To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken.
Maarten
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no **********************************************************************
What I've done for a closed path is to use a dynamic offset to first inset the path and then do another dynamic offset to bring it back out. When you bring it back out the corners will be rounded. However it's not exactly an accurate method. It rounds all corners of the path, not specific ones, and may not be what you're looking for. The steps I use are:
1. create path or convert original shape to a path 2. double-click the path object and then hit Ctrl-J (dynamic offset) 3. drag the shape inwards 4. convert the resulting inset shape into a path again (it's now an offset, not a path) 5. double-click the path object and then hit Ctrl-J (same as step 2) 6. this time drag the shape back outwards - you should see the corners become rounded.
Note, if you do this on an open path it will close the path automatically and you're results might not be what you're looking for.
Like I said, it's a very simplistic method. It might be a sledgehammer when you're actually looking for a surgical scalpel. :)
RQ
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Hey people,
Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke to fill, break fill apart and remove the inner path. Is there an easier way?
To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken.
Maarten
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Well, orthopedic surgeons also use sledge hammers :D Thanks for the tip, it's quite a obvious solution indeed. But it makes me think of another strange thing in Inskcape:
Wenn chosing "inset" or "outset" when working on a pixel scale, (icon), the outcome usualy is horrible! Dynamic outset doesn't have this problem. Anybody know what's going on?
________________________________
From: inkscape-user-bounces@lists.sourceforge.net [mailto:inkscape-user-bounces@lists.sourceforge.net] On Behalf Of Richard Querin Sent: 18. oktober 2007 12:09 To: Inkscape User Community Subject: Re: [Inkscape-user] Rounded corners
What I've done for a closed path is to use a dynamic offset to first inset the path and then do another dynamic offset to bring it back out. When you bring it back out the corners will be rounded. However it's not exactly an accurate method. It rounds all corners of the path, not specific ones, and may not be what you're looking for. The steps I use are:
1. create path or convert original shape to a path 2. double-click the path object and then hit Ctrl-J (dynamic offset) 3. drag the shape inwards 4. convert the resulting inset shape into a path again (it's now an offset, not a path) 5. double-click the path object and then hit Ctrl-J (same as step 2) 6. this time drag the shape back outwards - you should see the corners become rounded.
Note, if you do this on an open path it will close the path automatically and you're results might not be what you're looking for.
Like I said, it's a very simplistic method. It might be a sledgehammer when you're actually looking for a surgical scalpel. :)
RQ
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Hey people, Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke to fill, break fill apart and remove the inner path. Is there an easier way? To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken. Maarten ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.powel.no ********************************************************************** ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Maarten,
I've noticed the same issue with the inset and outset functions in inkscape. Unfortunately, I don't have a good answer for you.
I might have a more elegant answer for your previous question though.
1. Select the node tool and add an additional node on either side of the corner you want to smooth. 2. Select the two "new" segments. 3. Use the make selected segments curves options. 4. Delete the node at the corner. 5. Tweek as appropriate.
I'm not quite sure if this is what you're looking for, but it does work well for some applications.
A
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Well, orthopedic surgeons also use sledge hammers :D Thanks for the tip, it's quite a obvious solution indeed. But it makes me think of another strange thing in Inskcape:
Wenn chosing "inset" or "outset" when working on a pixel scale, (icon), the outcome usualy is horrible! Dynamic outset doesn't have this problem. Anybody know what's going on?
*From:* inkscape-user-bounces@lists.sourceforge.net [mailto: inkscape-user-bounces@lists.sourceforge.net] *On Behalf Of *Richard Querin *Sent:* 18. oktober 2007 12:09 *To:* Inkscape User Community *Subject:* Re: [Inkscape-user] Rounded corners
What I've done for a closed path is to use a dynamic offset to first inset the path and then do another dynamic offset to bring it back out. When you bring it back out the corners will be rounded. However it's not exactly an accurate method. It rounds all corners of the path, not specific ones, and may not be what you're looking for. The steps I use are:
- create path or convert original shape to a path
- double-click the path object and then hit Ctrl-J (dynamic offset)
- drag the shape inwards
- convert the resulting inset shape into a path again (it's now an
offset, not a path) 5. double-click the path object and then hit Ctrl-J (same as step 2) 6. this time drag the shape back outwards - you should see the corners become rounded.
Note, if you do this on an open path it will close the path automatically and you're results might not be what you're looking for.
Like I said, it's a very simplistic method. It might be a sledgehammer when you're actually looking for a surgical scalpel. :)
RQ
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Hey people,
Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke to fill, break fill apart and remove the inner path. Is there an easier way?
To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken.
Maarten
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Hey Aaron,
Thanks for your reply. It works, and if the rounded corner would become too big, you can actually repeat the "extra node"-button a couple of times - each time the segments get divided into two. In this way, you don't have to reposition the node. But the problem with this approach is that I would like to have the handles for the rounded corner in the exact right place - something I can't manage "on the eye" or "by hand", if you get what I mean...
Maarten
-----Original Message----- From: inkscape-user-bounces@lists.sourceforge.net on behalf of Aaron Elmquist Sent: Sun 21-Oct-07 04:25 To: Inkscape User Community Subject: Re: [Inkscape-user] Rounded corners
Maarten,
I've noticed the same issue with the inset and outset functions in inkscape. Unfortunately, I don't have a good answer for you.
I might have a more elegant answer for your previous question though.
1. Select the node tool and add an additional node on either side of the corner you want to smooth. 2. Select the two "new" segments. 3. Use the make selected segments curves options. 4. Delete the node at the corner. 5. Tweek as appropriate.
I'm not quite sure if this is what you're looking for, but it does work well for some applications.
A
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Well, orthopedic surgeons also use sledge hammers :D Thanks for the tip, it's quite a obvious solution indeed. But it makes me think of another strange thing in Inskcape:
Wenn chosing "inset" or "outset" when working on a pixel scale, (icon), the outcome usualy is horrible! Dynamic outset doesn't have this problem. Anybody know what's going on?
*From:* inkscape-user-bounces@lists.sourceforge.net [mailto: inkscape-user-bounces@lists.sourceforge.net] *On Behalf Of *Richard Querin *Sent:* 18. oktober 2007 12:09 *To:* Inkscape User Community *Subject:* Re: [Inkscape-user] Rounded corners
What I've done for a closed path is to use a dynamic offset to first inset the path and then do another dynamic offset to bring it back out. When you bring it back out the corners will be rounded. However it's not exactly an accurate method. It rounds all corners of the path, not specific ones, and may not be what you're looking for. The steps I use are:
- create path or convert original shape to a path
- double-click the path object and then hit Ctrl-J (dynamic offset)
- drag the shape inwards
- convert the resulting inset shape into a path again (it's now an
offset, not a path) 5. double-click the path object and then hit Ctrl-J (same as step 2) 6. this time drag the shape back outwards - you should see the corners become rounded.
Note, if you do this on an open path it will close the path automatically and you're results might not be what you're looking for.
Like I said, it's a very simplistic method. It might be a sledgehammer when you're actually looking for a surgical scalpel. :)
RQ
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Hey people,
Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke to fill, break fill apart and remove the inner path. Is there an easier way?
To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken.
Maarten
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Maarten,
You can place nodes exactly by adjusting their position in the XML editor. It's not real hard. Just open the editor find the right location and type the correct value. Also, I wouldn't use the add node button. Have the node tool active. Double click on the segment about where you would like the node to be place and one will be added there. Tweeking can be done through the XML editor or with the grides/guidlines and the arrow keys.
Aaron
On 10/21/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Hey Aaron,
Thanks for your reply. It works, and if the rounded corner would become too big, you can actually repeat the "extra node"-button a couple of times - each time the segments get divided into two. In this way, you don't have to reposition the node. But the problem with this approach is that I would like to have the handles for the rounded corner in the exact right place - something I can't manage "on the eye" or "by hand", if you get what I mean...
Maarten
-----Original Message----- From: inkscape-user-bounces@lists.sourceforge.net on behalf of Aaron Elmquist Sent: Sun 21-Oct-07 04:25 To: Inkscape User Community Subject: Re: [Inkscape-user] Rounded corners
Maarten,
I've noticed the same issue with the inset and outset functions in inkscape. Unfortunately, I don't have a good answer for you.
I might have a more elegant answer for your previous question though.
- Select the node tool and add an additional node on either side of the
corner you want to smooth. 2. Select the two "new" segments. 3. Use the make selected segments curves options. 4. Delete the node at the corner. 5. Tweek as appropriate.
I'm not quite sure if this is what you're looking for, but it does work well for some applications.
A
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
Well, orthopedic surgeons also use sledge hammers :D Thanks for the
tip,
it's quite a obvious solution indeed. But it makes me think of another strange thing in Inskcape:
Wenn chosing "inset" or "outset" when working on a pixel scale, (icon), the outcome usualy is horrible! Dynamic outset doesn't have this
problem.
Anybody know what's going on?
*From:* inkscape-user-bounces@lists.sourceforge.net [mailto: inkscape-user-bounces@lists.sourceforge.net] *On Behalf Of *Richard
Querin
*Sent:* 18. oktober 2007 12:09 *To:* Inkscape User Community *Subject:* Re: [Inkscape-user] Rounded corners
What I've done for a closed path is to use a dynamic offset to first
inset
the path and then do another dynamic offset to bring it back out. When
you
bring it back out the corners will be rounded. However it's not exactly
an
accurate method. It rounds all corners of the path, not specific ones,
and
may not be what you're looking for. The steps I use are:
- create path or convert original shape to a path
- double-click the path object and then hit Ctrl-J (dynamic offset)
- drag the shape inwards
- convert the resulting inset shape into a path again (it's now an
offset, not a path) 5. double-click the path object and then hit Ctrl-J (same as step 2) 6. this time drag the shape back outwards - you should see the corners become rounded.
Note, if you do this on an open path it will close the path
automatically
and you're results might not be what you're looking for.
Like I said, it's a very simplistic method. It might be a sledgehammer when you're actually looking for a surgical scalpel. :)
RQ
On 10/18/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...>
wrote:
Hey people,
Is there an easy way to round corners in a path? All I could think off now is to instet the path, give it a realy big width, convert stroke
to
fill, break fill apart and remove the inner path. Is there an easier way?
To my knoledge, no other graphic programs outside the CAD-world have this functionality, but I might be mistaken.
Maarten
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.powel.no
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
-- Like open source illustration? - Visit OpenSourceStyle.blogspot.com for Tutorial, Tips, Projects, and more.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 10/11/07, Maarten van der Velde <Maarten.van-der-Velde@...2171...> wrote:
I'm just wondering why it happens? Are the names for the gradients assigned based on a incrementing counter? Can't we just assign them random numbers?
In my particular case (three images from OpenClipArt), the same image appears to have been used and the only thing done between them is the tweaking of colours in the definition of radialGradients and linearGradients. Since it is easier to edit an existing gradient rather than rename and edit, I suspect that's what the original author did.
mG.
On Thu, 11 Oct 2007 17:34:57 +0200, "Maarten van der Velde" <Maarten.van-der-Velde@...2171...> wrote:
I'm just wondering why it happens? Are the names for the gradients assigned based on a incrementing counter? Can't we just assign them random numbers?
Random numbers aren't guaranteed to be unique either.
-mental
On Thu, 11 Oct 2007 11:31:47 +0200, Chris Lilley <chris@...214...> wrote:
However, detecting a potential id conflict between the current document and the copy/paste buffer when paste is selected (and warning, offering to fix up the conflicts before pasting) would be a nice feature.
Yes; unfortunately the existing copy/paste implementation just blindly mashes an XML fragment into the target document. ID conflicts are detected and resolved by the target document, but at that point it is too late to update references to conflicting objects.
The copy/paste code needs to be rewritten to work at the SVG object model level (SPObject) rather than at the XML level, so that the required knowledge to update all the various reference attributes and properties is available, and can be done in advance. That's basically the "grand plan" bulia was alluding to.
(It would be nice if the copy/paste stuff integrated with the system clipboard as well.)
-mental
participants (10)
-
Aaron Elmquist -
bulia byak -
Chris Lilley -
greg fenton -
m h -
Maarten van der Velde -
MenTaLguY -
Michael Wybrow -
Richard Querin -
Terry Brown