inkscape bucket fill?
hello everyone,
i've been dabbling with svg cartoons. i've been scanning black and white line drawings and converting them to svgs with the trace bitmap tool. i then colour them in by drawing blocks of colour and lowering them behind the outline. this is an incredibly time consuming way of doing things and i was wondering if there is a quicker way of doing it that i'm missing.
i've tried exporting to a bitmap, using the gimp to bucket fill the gaps and then tracing it back to an svg again, but it's not the most elegant way of working.
is there some kind of tool in inkscape equivalent to the bucket fill tool in gimp?
thanks. john michaelson.
On Wed, May 03, 2006 at 09:30:25AM +0930, j michaelson wrote:
hello everyone,
i've been dabbling with svg cartoons. i've been scanning black and white line drawings and converting them to svgs with the trace bitmap tool. i then colour them in by drawing blocks of colour and lowering them behind the outline. this is an incredibly time consuming way of doing things and i was wondering if there is a quicker way of doing it that i'm missing.
i've tried exporting to a bitmap, using the gimp to bucket fill the gaps and then tracing it back to an svg again, but it's not the most elegant way of working.
is there some kind of tool in inkscape equivalent to the bucket fill tool in gimp?
No, but there's been a proposal to implement a feature like this. The problem is that it sounds easy, but actually would be rather tricky to implement. If anyone feels like hacking on code for this, Bulia can explain his ideas, or see the RFE tracker for some other ideas.
Bryce
hello bryce,
i did some looking for the feature request and came up with these two pages.
http://sourceforge.net/tracker/?group_id=93438&atid=604309&func=deta... https://sourceforge.net/tracker/?func=detail&atid=604309&aid=1275286...
there was some interesting workarounds on there that i'vebeen playing with. what i do now is..... 1. put a block of rectangle of colour behind the shape i want to fill. 2. duplicate the vector that forms the outlines. 3. select both the outline and the block of colour. 4. use path / division to seperate the shape i need from the excess that i don't. 5. remove the excess and delete it.
it's still slow and awkward but it's not as slow as drawing the shape by hand and it's way cleaner than having to convert to bitmap and back every time i want to fill.
do you have any idea what's happening with this feature request? i'm getting the sad impression that it's dead in the water. i hope not as it would be a fantastic tool if someone could figure out how to do it.
thanks for your help. john michaelson.
On 5/3/06, Bryce Harrington <bryce@...983...> wrote:
On Wed, May 03, 2006 at 09:30:25AM +0930, j michaelson wrote:
hello everyone,
i've been dabbling with svg cartoons. i've been scanning black and white line drawings and converting them to svgs with the trace bitmap tool. i then colour them in by drawing blocks of colour and lowering them behind the outline. this is an incredibly time consuming way of doing things and i was wondering if there is a quicker way of doing it that i'm missing.
i've tried exporting to a bitmap, using the gimp to bucket fill the gaps and then tracing it back to an svg again, but it's not the most elegant way of working.
is there some kind of tool in inkscape equivalent to the bucket fill tool in gimp?
No, but there's been a proposal to implement a feature like this. The problem is that it sounds easy, but actually would be rather tricky to implement. If anyone feels like hacking on code for this, Bulia can explain his ideas, or see the RFE tracker for some other ideas.
Bryce
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
further thoughts on the subject. could a bucket fill type effect be acheived in this way?
the user sets up a selection box to define where the fill needs to be done. they then click on the space they want to fill within that area. once they have done these two actions then inkscape can.... 1. make a vector rectangle of the same dimensions as the selection box. 2. calculate which which vectors overlap that rectangle. 3. use a version of path-difference to cut lumps out of the rectangle for every vector which falls within it's boundaries, leaving a load of little chunks which would relate to every space in that rectangle. 4. throw away all the little chunks except the one is where the cursor was when the click occured.
i imagine it would be slow and inefficient, but it might act as a temporary fix until a proper bucket fill comes along.
sadly i don't know how to program or script, but hopefully someone with the necessary talents might consider trying this.
john michaelson.
On 5/3/06, j michaelson <jmichaelson@...155...> wrote:
hello bryce,
i did some looking for the feature request and came up with these two pages.
http://sourceforge.net/tracker/?group_id=93438&atid=604309&func=deta... https://sourceforge.net/tracker/?func=detail&atid=604309&aid=1275286...
there was some interesting workarounds on there that i'vebeen playing with. what i do now is.....
- put a block of rectangle of colour behind the shape i want to fill.
- duplicate the vector that forms the outlines.
- select both the outline and the block of colour.
- use path / division to seperate the shape i need from the excess
that i don't. 5. remove the excess and delete it.
it's still slow and awkward but it's not as slow as drawing the shape by hand and it's way cleaner than having to convert to bitmap and back every time i want to fill.
do you have any idea what's happening with this feature request? i'm getting the sad impression that it's dead in the water. i hope not as it would be a fantastic tool if someone could figure out how to do it.
thanks for your help. john michaelson.
On 5/3/06, Bryce Harrington <bryce@...983...> wrote:
On Wed, May 03, 2006 at 09:30:25AM +0930, j michaelson wrote:
hello everyone,
i've been dabbling with svg cartoons. i've been scanning black and white line drawings and converting them to svgs with the trace bitmap tool. i then colour them in by drawing blocks of colour and lowering them behind the outline. this is an incredibly time consuming way of doing things and i was wondering if there is a quicker way of doing it that i'm missing.
i've tried exporting to a bitmap, using the gimp to bucket fill the gaps and then tracing it back to an svg again, but it's not the most elegant way of working.
is there some kind of tool in inkscape equivalent to the bucket fill tool in gimp?
No, but there's been a proposal to implement a feature like this. The problem is that it sounds easy, but actually would be rather tricky to implement. If anyone feels like hacking on code for this, Bulia can explain his ideas, or see the RFE tracker for some other ideas.
Bryce
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
As long as we're discussing this, I'd like to suggest that a vector bucket-fill, if implemented, might be designed to be a little smarter than its bitmap cousin:
It would be nice to be able to control the "viscosity" of the paint, so that it won't spill through an infinitesimally small hole. One of the classic problems with the bucket fill in bitmap work is that you have to be very very careful about making sure that the region is completely sealed-up, to avoid the fill algorithm "leaking" and filling the whole page. This can take a lot of time.
I can think of two mathematical constraints that could be used for this:
1) A "brush size" -- if it can't fit through, it doesn't spill.
2) A constraint on the curvature of the perimeter (no extremely sharp turns as would occur at the spill point). Or possibly, the constraint is on the narrowness of the curve at that point.
#1 is probably the way to go for a bitmap-based fill. #2 might be easier to implement if the algorithm is curve-based. (?)
Another useful thing to control would be an "overfill" parameter -- the fill should actually be very slightly larger than the area it fills. This may seem unnecessary, but it's very useful in practice. Typically the "ink" layer will have thick enough lines to obscure errors in the "paint" layer. This would reduce the possibility of gaps and allow the user to manipulate the paint layer and put it back without having to be pixel-accurate.
This is actually an exact analog for how manual ink and paint is (or was) done on cels -- the front is inked, and the back painted to match, so that brush stroke errors are hidden by the thickness of the ink lines.
Cheers, Terry
On Thu, 04 May 2006 00:35:01 +0000 Terry Hancock <hancock@...1624...> wrote:
bulia byak wrote:
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
As long as we're discussing this, I'd like to suggest that a vector bucket-fill, if implemented, might be designed to be a little smarter than its bitmap cousin:
It would be nice to be able to control the "viscosity" of the paint, so that it won't spill through an infinitesimally small hole. One of the classic problems with the bucket fill in bitmap work is that you have to be very very careful about making sure that the region is completely sealed-up, to avoid the fill algorithm "leaking" and filling the whole page. This can take a lot of time.
I can think of two mathematical constraints that could be used for this:
A "brush size" -- if it can't fit through, it doesn't spill.
A constraint on the curvature of the perimeter (no extremely sharp
turns as would occur at the spill point). Or possibly, the constraint is on the narrowness of the curve at that point.
#1 is probably the way to go for a bitmap-based fill. #2 might be easier to implement if the algorithm is curve-based. (?)
Another useful thing to control would be an "overfill" parameter -- the fill should actually be very slightly larger than the area it fills. This may seem unnecessary, but it's very useful in practice. Typically the "ink" layer will have thick enough lines to obscure errors in the "paint" layer. This would reduce the possibility of gaps and allow the user to manipulate the paint layer and put it back without having to be pixel-accurate.
This is actually an exact analog for how manual ink and paint is (or was) done on cels -- the front is inked, and the back painted to match, so that brush stroke errors are hidden by the thickness of the ink lines.
Cheers, Terry
I definitely agree with you on this. A vector approach seems much more natural and flexible. I think the necessary code for working out the boundaries could well be useful for other similar operations. I just have a feeling that finding an area inside intersecting lines (that are not necessarily related to each other in any other ways) could turn out to be very useful.
On Thu, May 04, 2006 at 07:21:45PM +0100, Abrolag wrote:
I definitely agree with you on this. A vector approach seems much more natural and flexible. I think the necessary code for working out the boundaries could well be useful for other similar operations. I just have a feeling that finding an area inside intersecting lines (that are not necessarily related to each other in any other ways) could turn out to be very useful.
Which is a call for someone to pick up a Computational Geometry book if I ever heard one. I would suggest "Computational Geometry" by M. de Berg as a good starting place (and it will have the above problem in it)
Jeff
Jeffrey Brent McBeth wrote:
On Thu, May 04, 2006 at 07:21:45PM +0100, Abrolag wrote:
definitely agree with you on this. A vector approach seems much more natural and flexible. I think the necessary code for working out the boundaries could well be useful for other similar operations. I just have a feeling that finding an area inside intersecting lines (that are not necessarily related to each other in any other ways) could turn out to be very useful.
I'm not sure my comment necessarily advocates a vector approach. I think the minimum spill can be done by choosing the size of the "pixels" in the raster approach. I'm not sure which approach is smarter, but it seems like either would work.
Which is a call for someone to pick up a Computational Geometry book if I ever heard one. I would suggest "Computational Geometry" by M. de Berg as a good starting place (and it will have the above problem in it)
I agree. Thanks for the reference.
Cheers, Terry
On Thu, 4 May 2006, Terry Hancock wrote:
Date: Thu, 04 May 2006 00:35:01 +0000 From: Terry Hancock <hancock@...1624...> Reply-To: inkscape-user@lists.sourceforge.net To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] inkscape bucket fill?
bulia byak wrote:
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
As long as we're discussing this, I'd like to suggest that a vector bucket-fill, if implemented, might be designed to be a little smarter than its bitmap cousin:
the fill method is smarter in some applications than others. in Adobe Photoshop if you apply the bucket repeatedly on the same spot the colour gradually spreads out further and further much like a throwing down an actual bucket of paint in fact.
Is increasingly filling larger areas by repeated clicking something you think could be included in the design? This might be a good way to fill only a small area at first rather than trying to fill too much all at once and having to fill in the gaps to avoid leakage as described.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
After losing a few hours worth of work due to my own stupidity :P, I suddenly wondered if Inkscape has an autosave function or some sort of way to make a backup of whatever you're working on that can be recovered after a crash. I looked around but didn't find anything that looked promising. Is there such a feature? Are there plans to add a feature in the future?
The error, by the way, was generated when I tried to change the line width of multiple objects from .5 pt to .25 pt. Apparently that was too much for Inkscape to handle and it promptly crashed. Losing the data was my fault, though -- I got so wrapped up in what I was drawing that I forgot to save the !@#$% thing. *sob*
Christopher B. Wright (wrightc@...537...)
Christopher B. Wright wrote:
After losing a few hours worth of work due to my own stupidity :P, I suddenly wondered if Inkscape has an autosave function or some sort of way to make a backup of whatever you're working on that can be recovered after a crash. I looked around but didn't find anything that looked promising. Is there such a feature? Are there plans to add a feature in the future?
When Inkscape crashes it usually tells me it saved the document in my home dir (C:\Documents and Settings\Username on my system).
Jasper van de Gronde wrote:
Christopher B. Wright wrote:
After losing a few hours worth of work due to my own stupidity :P, I suddenly wondered if Inkscape has an autosave function or some sort of way to make a backup of whatever you're working on that can be recovered after a crash. I looked around but didn't find anything that looked promising. Is there such a feature? Are there plans to add a feature in the future?
When Inkscape crashes it usually tells me it saved the document in my home dir (C:\Documents and Settings\Username on my system).
I just found it there! There wasn't any message to that effect, though. Thanks!
Chris
On 5/5/06, Christopher B. Wright <wrightc@...537...> wrote:
I just found it there! There wasn't any message to that effect, though. Thanks!
Actually most likely there was a message, but it was displayed to the console from which you run Inkscape, so if you run it not from the console then you can't see it.
Generally, if you're having any kind of problems, it's better to run it from the console as you will see various additional warnings.
As for your crash, if you can reproduce it with a current development snapshot, please submit a bug report.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 5/5/06, Christopher B. Wright <wrightc@...537...> wrote:
I just found it there! There wasn't any message to that effect, though. Thanks!
Actually most likely there was a message, but it was displayed to the console from which you run Inkscape, so if you run it not from the console then you can't see it.
Generally, if you're having any kind of problems, it's better to run it from the console as you will see various additional warnings.
This is the first problem I've really had with Inkscape in a while. It surprised the heck out of me.
As for your crash, if you can reproduce it with a current development snapshot, please submit a bug report.
I've been unable to reproduce the problem thus far.
Christopher B. Wright (wrightc@...537...)
Christopher B. Wright wrote:
After losing a few hours worth of work due to my own stupidity :P, I suddenly wondered if Inkscape has an autosave function or some sort of way to make a backup of whatever you're working on that can be recovered after a crash. I looked around but didn't find anything that looked promising. Is there such a feature? Are there plans to add a feature in the future?
The error, by the way, was generated when I tried to change the line width of multiple objects from .5 pt to .25 pt. Apparently that was too much for Inkscape to handle and it promptly crashed. Losing the data was my fault, though -- I got so wrapped up in what I was drawing that I forgot to save the !@#$% thing. *sob*
You don't say what O/S you're using. On Linux, Inkscape puts autosave files in your ~/.inkscape directory. All you have to do is rename them to *.svg and open them again. I don't know about other platforms.
I think it actually tries to autosave before crashing when something goes wrong.
Cheers, Terry
On Fri, 05 May 2006 19:39:37 +0000, Terry Hancock <hancock@...1624...> wrote:
I think it actually tries to autosave before crashing when something goes wrong.
Yes; Inkscape makes a best effort to save copies of all open files somewhere before crashing.
(To avoid the risk of corruption, it won't save over the original file.)
-mental
MenTaLguY wrote:
On Fri, 05 May 2006 19:39:37 +0000, Terry Hancock <hancock@...1624...> wrote:
I think it actually tries to autosave before crashing when something goes wrong.
Yes; Inkscape makes a best effort to save copies of all open files somewhere before crashing. (To avoid the risk of corruption, it won't save over the original file.)
Of course, it goes without saying that a crash means something you didn't predict happened with the code, so I'm a little distrustful of Inkscape's ability to do this.
Would it make more sense to do time-based or even idle-time-based autosaves (I.e. if nothing happens for N minutes, and the current data is not saved, make an automatic backup)? I know some programs have implemented features like this. It can be irritating if it decides to do a backup right when you're starting to do something, but it would be really nice if something calls you away from your project, and you forget to save it.
Of course, that's a bad habit, but still...
Cheers, Terry
On Fri, 2006-05-05 at 23:34 +0000, Terry Hancock wrote:
Would it make more sense to do time-based or even idle-time-based autosaves (I.e. if nothing happens for N minutes, and the current data is not saved, make an automatic backup)? I know some programs have implemented features like this. It can be irritating if it decides to do a backup right when you're starting to do something, but it would be really nice if something calls you away from your project, and you forget to save it.
The big problem is really how to make the autosave parallelizable so it can work in the background. It's not just a matter of doing it in another thread -- with the current data structures, you'd still have to lock all the data structures while saving, still bringing the main thread to a halt.
If autosave could be made to work seamlessly in the background, then I wouldn't really object to it. I really like the way Rosegarden does autosaves.
-mental
MenTaLguY wrote:
On Fri, 2006-05-05 at 23:34 +0000, Terry Hancock wrote:
Would it make more sense to do time-based or even idle-time-based autosaves (I.e. if nothing happens for N minutes, and the current data is not saved, make an automatic backup)? I know some programs have implemented features like this. It can be irritating if it decides to do a backup right when you're starting to do something, but it would be really nice if something calls you away from your project, and you forget to save it.
The big problem is really how to make the autosave parallelizable so it can work in the background. It's not just a matter of doing it in another thread -- with the current data structures, you'd still have to lock all the data structures while saving, still bringing the main thread to a halt.
If autosave could be made to work seamlessly in the background, then I wouldn't really object to it. I really like the way Rosegarden does autosaves.
Even if it causes a "freeze", it might be desireable, if it only worked after a configurable idle-time and could be turned off. I think the last Corel Draw I used did something like this (of course, that was Corel Draw 3!).
MenTaLguY wrote:
If autosave could be made to work seamlessly in the background, then I wouldn't really object to it. I really like the way Rosegarden does autosaves.
If inkscape uses the Command Pattern internally, you could simply write a log of all the actions the user makes. This would take little time.
The second solution would be to create a copy of the whole model and save that (kind of cut&paste internally).
That would use some memory but would be very safe and that's what we want.
Regards,
Terry Hancock wrote:
... You don't say what O/S you're using. On Linux, Inkscape puts autosave files in your ~/.inkscape directory. All you have to do is rename them to *.svg and open them again. I don't know about other platforms.
BTW, was there a specific reason for choosing these directories? At least on Windows it might make more sense to save it to the "My Documents" directory (or something similar), as the current location (the user's "home" directory) isn't exactly a well-known directory on Windows (most users probably don't even know where it is and certainly don't expect to ever have to look there).
On May 6, 2006, at 1:40 AM, Jasper van de Gronde wrote:
BTW, was there a specific reason for choosing these directories? At least on Windows it might make more sense to save it to the "My Documents" directory (or something similar), as the current location (the user's "home" directory) isn't exactly a well-known directory on Windows (most users probably don't even know where it is and certainly don't expect to ever have to look there).
"My Documents" takes jumping through lots of COM hoops, and is different on earlier versions of Windows. The other code was already around for Unix/Linux support.
So it's basically just what was simplest early on to implement.
Jon A. Cruz wrote:
On May 6, 2006, at 1:40 AM, Jasper van de Gronde wrote:
BTW, was there a specific reason for choosing these directories? At least on Windows it might make more sense to save it to the "My Documents" directory (or something similar), as the current location (the user's "home" directory) isn't exactly a well-known directory on Windows (most users probably don't even know where it is and certainly don't expect to ever have to look there).
"My Documents" takes jumping through lots of COM hoops, and is different on earlier versions of Windows. The other code was already around for Unix/Linux support.
So it's basically just what was simplest early on to implement.
How about using SHGetSpecialFolderPath? Should work on pretty much any Windows system and is reasonably easy to use.
Example usage (prints the location of the My Documents directory for the current user): #define _WIN32_IE 0x0400 #include <shlobj.h> #include <stdio.h>
int main() { char path[MAX_PATH+1]; SHGetSpecialFolderPath(NULL, path, CSIDL_PERSONAL, 0); printf("My docs: %s\n", path); return 0; }
On May 6, 2006, at 2:16 AM, Jasper van de Gronde wrote:
How about using SHGetSpecialFolderPath? Should work on pretty much any Windows system and is reasonably easy to use.
Example usage (prints the location of the My Documents directory for the current user): #define _WIN32_IE 0x0400
Nope!
fails on Windows 95 and Windows NT 4.0 that don't have extra newer stuff installed.
:-)
(notice that say I have version such-and-such of Internet Explorer or later)
Jon A. Cruz wrote:
On May 6, 2006, at 2:16 AM, Jasper van de Gronde wrote:
How about using SHGetSpecialFolderPath? Should work on pretty much any Windows system and is reasonably easy to use.
Example usage (prints the location of the My Documents directory for the current user):
#define _WIN32_IE 0x0400
Nope!
fails on Windows 95 and Windows NT 4.0 that don't have extra newer stuff installed.
:-)
(notice that say I have version such-and-such of Internet Explorer or later)
It would, but only on really ancient versions, and as I understood they're not supported anyway (and they probably don't have a My Documents directory to begin with, so Inkscape could fall back on the current behaviour if it isn't supported). If it's deemed too much trouble then that's fine, but I think it would be nice if Inkscape's autosave feature would be a bit more obvious by saving files to a less obscure directory. Of course alternatively (or additionally) Inkscape could offer to open auto-saved documents on the next launch, but that might be quite a bit more complex to do correctly.
On May 6, 2006, at 6:11 AM, Jasper van de Gronde wrote:
It would, but only on really ancient versions, and as I understood they're not supported anyway (and they probably don't have a My Documents directory to begin with, so Inkscape could fall back on the current behaviour if it isn't supported). If it's deemed too much trouble then that's fine, but I think it would be nice if Inkscape's autosave feature would be a bit more obvious by saving files to a less obscure directory. Of course alternatively (or additionally) Inkscape could offer to open auto-saved documents on the next launch, but that might be quite a bit more complex to do correctly.
Well... we try to support as much as we can. In fact, some of those issues were hit by actual users.
Now... you'd also just asked about the history on this. Moving forward, if you don't see it already entered then go ahead and set a bug for this. We may even have more code around, and just need to use it in a more centralized manner.
Jon A. Cruz wrote:
On May 6, 2006, at 6:11 AM, Jasper van de Gronde wrote:
It would, but only on really ancient versions, and as I understood they're not supported anyway (and they probably don't have a My Documents directory to begin with, so Inkscape could fall back on the current behaviour if it isn't supported). If it's deemed too much trouble then that's fine, but I think it would be nice if Inkscape's autosave feature would be a bit more obvious by saving files to a less obscure directory. Of course alternatively (or additionally) Inkscape could offer to open auto-saved documents on the next launch, but that might be quite a bit more complex to do correctly.
Well... we try to support as much as we can. In fact, some of those issues were hit by actual users.
I can apreciate that, it's just that I thought GTK wasn't supported anymore on Win9x at all (not sure about WinNT 4 though). If you know of anyone who can test with such systems I wouldn't mind seeing if the code I mailed later does work on such systems.
Now... you'd also just asked about the history on this. Moving forward, if you don't see it already entered then go ahead and set a bug for this. We may even have more code around, and just need to use it in a more centralized manner.
If you (or anyone else) can point me in the right direction, and nobody objects to such a change, I wouldn't mind writing a patch (assuming the tests mentioned above have positive results) and submitting it somewhere. I have been able to build Inkscape in the past. If you think this could better be solved differently or something, I'd also be happy to simply file a bug/feature request.
On May 9, 2006, at 1:55 AM, Jasper van de Gronde wrote:
I can apreciate that, it's just that I thought GTK wasn't supported anymore on Win9x at all (not sure about WinNT 4 though). If you know of anyone who can test with such systems I wouldn't mind seeing if the code I mailed later does work on such systems.
Not quite that it's not supported anymore, but that there're some bugs preventing the Win32 version from working on 9x, and no programmer bodies to take time chasing those down.
On Tue, 9 May 2006, Jon A. Cruz wrote:
Date: Tue, 9 May 2006 08:15:27 -0700 From: Jon A. Cruz <jon@...204...> Reply-To: inkscape-user@lists.sourceforge.net To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] Win32 My Documents
On May 9, 2006, at 1:55 AM, Jasper van de Gronde wrote:
I can apreciate that, it's just that I thought GTK wasn't supported anymore on Win9x at all (not sure about WinNT 4 though). If you know of anyone who can test with such systems I wouldn't mind seeing if the code I mailed later does work on such systems.
Not quite that it's not supported anymore, but that there're some bugs preventing the Win32 version from working on 9x, and no programmer bodies to take time chasing those down.
I believe there are still some Windows 9x users who are able to get Inkscape running with older versions of Gtk by mixing and matching the necessary DLLs. This works because more recent version Gtk+ requires Cairo but Inkscape doesn't yet, but does require other recent improvements in Gtk.
Jon A. Cruz wrote:
On May 6, 2006, at 2:16 AM, Jasper van de Gronde wrote:
How about using SHGetSpecialFolderPath? Should work on pretty much any Windows system and is reasonably easy to use.
Example usage (prints the location of the My Documents directory for the current user):
#define _WIN32_IE 0x0400
Nope!
fails on Windows 95 and Windows NT 4.0 that don't have extra newer stuff installed.
:-)
(notice that say I have version such-and-such of Internet Explorer or later)
For reference, wxWidgets uses SHGetFolderPath followed by SHGetSpecialFolderPath, if they both fail (or if they don't exist) it uses SHGetSpecialFolderLocation, which is apparently available pretty much everywhere. I'm not sure why they first try SHGetSpecialFolderPath, as far as I can see it mostly functions as a wrapper for SHGetSpecialFolderLocation. In any case, the following should also work on Windows NT 4 and Windows 95 (probably without too much extra installed, as there is no IF _WIN32_IE >= ... around the function prototypes in shlobj.h):
#include <shlobj.h> #include <stdio.h>
int main() { char path[MAX_PATH]; LPITEMIDLIST itemIdList; SHGetSpecialFolderLocation(NULL, CSIDL_PERSONAL, &itemIdList); SHGetPathFromIDList(itemIdList, path);
IMalloc* allocPtr; SHGetMalloc(&allocPtr); allocPtr->Free(itemIdList); allocPtr->Release();
printf("My docs: %s\n", path); return 0; }
Terry Hancock wrote:
You don't say what O/S you're using. On Linux, Inkscape puts autosave files in your ~/.inkscape directory. All you have to do is rename them to *.svg and open them again. I don't know about other platforms.
I think it actually tries to autosave before crashing when something goes wrong.
I'm running Kubuntu. It actually put the file in my home directory, not /.inkscape.
Christopher B. Wright (wrightc@...537...)
Christopher B. Wright wrote:
Terry Hancock wrote:
You don't say what O/S you're using. On Linux, Inkscape puts autosave files in your ~/.inkscape directory. All you have to do is rename them to *.svg and open them again. I don't know about other platforms.
I think it actually tries to autosave before crashing when something goes wrong.
I'm running Kubuntu. It actually put the file in my home directory, not /.inkscape.
Christopher B. Wright (wrightc@...537...)
Hmm... /.inkscape and ~/.inkscape are not the same directory -- the latter means /home/<your-username>/.inkscape/ so, putting it in ~/.inkscape would be under your home directory. Or did you mean it dropped it straight into ~?
This is 0.41, though -- we use Debian, and we haven't upgraded to Etch yet.
Cheers, Terry
Terry Hancock wrote:
Another useful thing to control would be an "overfill" parameter -- the fill should actually be very slightly larger than the area it fills.
There is no need for that. In the end, you'll have a polygon. To achieve the "overfill" effect, just add an a line style and give it some width.
or use outset on it...
--- Aaron Digulla <digulla@...310...> wrote:
Terry Hancock wrote:
Another useful thing to control would be an "overfill" parameter --
the
fill should actually be very slightly larger than the area it
fills.
There is no need for that. In the end, you'll have a polygon. To achieve the "overfill" effect, just add an a line style and give it some width.
-- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.philmann-dark.de/
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da...
Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
i was thinking that some kind of overfill would be nice, adding line style seems to be a sensible way of getting that effect.
john michaelson.
On 5/10/06, Aaron Digulla <digulla@...310...> wrote:
Terry Hancock wrote:
Another useful thing to control would be an "overfill" parameter -- the fill should actually be very slightly larger than the area it fills.
There is no need for that. In the end, you'll have a polygon. To achieve the "overfill" effect, just add an a line style and give it some width.
-- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.philmann-dark.de/
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
hello bulia,
i reckon you're right, the rectangle and click thing would be an ugly way of working.
john michaelson.
On 5/4/06, bulia byak <buliabyak@...155...> wrote:
What you describe is similar to one of the 2 proposed approaches, using boolops. So I don't think it's much of a "temporary fix" - it's almost the real thing, in fact :)
I don't think forcing the user to draw a rect is a good idea. Bucket fill works without it in raster editors, and it should work the same in vector.
And personally, I'm much more in favor of the other approach, using bitmap fill algorithm over the rasterized image and then tracing the result. This way may sound more contrived, but it's actually more natural and universal. See this RFE for details:
http://sourceforge.net/tracker/index.php?func=detail&aid=1123138&gro...
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&d... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
j michaelson wrote:
hello everyone,
i've been dabbling with svg cartoons. i've been scanning black and white line drawings and converting them to svgs with the trace bitmap tool. i then colour them in by drawing blocks of colour and lowering them behind the outline. this is an incredibly time consuming way of doing things and i was wondering if there is a quicker way of doing it that i'm missing.
i've tried exporting to a bitmap, using the gimp to bucket fill the gaps and then tracing it back to an svg again, but it's not the most elegant way of working.
Here is an idea: Can you bucket fill in GIMP while using a second layer?
Then you could do this:
1. Export as bitmap (Inkscape) 2. Put the bitmap in layer 1 (GIMP) 3. Create layer 2 4. Create the fills in layer 2 5. Delete layer 1 6. Save the new image (just the fills) 7. Put the image behind the outlines
participants (14)
-
Aaron Digulla -
Abrolag -
Alan Horkan -
Bryce Harrington -
bulia byak -
Christopher B. Wright -
j michaelson -
Jasper van de Gronde -
Jeffrey Brent McBeth -
John Cliff -
Jon A. Cruz -
Karol Krenski -
MenTaLguY -
Terry Hancock