Just started trying to figure out Inkscape. Looks very nice so far. Never have really been able to get comfortable with Illustrator. Photoshop I'm ok with, but Illustrator just always seemed ... weird to me. But Inkscape feels pretty natural right from the start.
Love the python scripting too. Can't wait to start tinkering with it. I have done a bit of research on manipulating drawings and have plans for more things. (http://www.cavie-x.net/doodle/) It might be nice to implement future things as Inkscape Python scripts or perhaps more full-fledged plugins.
Stroke patterns seem to be limited to axis-aligned textures? Is there any way to transform the pattern applied to the stroke, at least in global coordinates? It would also be nice to be able to apply a texture in a curvilinear coordinate system relative to the stroke itself, with x being the direction tangent to the stroke, and y perpendicular to it. Being able to do curve-relative mappings opens the door to lots of possibilities. Like Hsu's "Skeletal Strokes" (which I see someone has already noted on the wiki: http://wiki.inkscape.org/wiki/index.php/Expression)
Why are spirals and stars top level tools? Seems very odd to have two such niche items on the main toolbar. Are they actually used that often? Why not gears or block arrows or speech bubbles or ... etc.
I'm curious about the choice of usage for Tab and Space keys. Space as select tool toggle is reasonable, since that is pretty frequently used. Still, seems to me like Photoshop's hold-toggle for canvas panning is a better option (i.e. needed more frequently), but easy access to the selection tool is also nice. But Tab as "select next" seems like a waste of prime keyboard real estate. I don't see how this is useful once you have more than a dozen or so elements in your drawing. Some kind of hide/reveal function might be good for this.
Is there a way to hide everything but the current selection? Or to use outline rendering for everything but the current selection? I was playing around with editing the about.svg splash screen and with all the blurring going on rendering was very slow when zoomed in. Outline mode fixed the speed, but then it's hard to tell what the current thing I'm editing really looks like. Anyway more flexible control over the rendering quality seems like it would be useful. An intermediate between outline and full would be nice too. It would basically turn off expensive effects like blur and just do a simple color rendering.
Finally seems like there's no way to customize key bindings right now?
That's all for now.
Thanks!
--bb
On Apr 2, 2007, at 8:10 PM, Bill Baxter wrote:
Finally seems like there's no way to customize key bindings right now?
http://wiki.inkscape.org/wiki/index.php/ ReleaseNotes045#Keyboard_profiles
http://wiki.inkscape.org/wiki/index.php/ ReleaseNotes044#Configurable_keyboard
Very nice. Thanks. Though I have found that my master plan to remap Tab to DialogsToggle is somewhat foiled by the fact that the dialogs themselves eat tab keys. Oh well.
--bb
On 4/3/07, Jon A. Cruz <jon@...204...> wrote:
On Apr 2, 2007, at 8:10 PM, Bill Baxter wrote:
Finally seems like there's no way to customize key bindings right now? http://wiki.inkscape.org/wiki/index.php/ReleaseNotes045#Keyboard_profiles
http://wiki.inkscape.org/wiki/index.php/ReleaseNotes044#Configurable_keyboar...
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Am Dienstag, den 03.04.2007, 12:10 +0900 schrieb Bill Baxter:
Anyway more flexible control over the rendering quality seems like it would be useful. An intermediate between outline and full would be nice too. It would basically turn off expensive effects like blur and just do a simple color rendering.
I'm all for it. I like the xara way to handle this: there is a little slider in the gui wich sets the quality. It turns out everything slowing the rendering down, for example Antialiasing. But the main performance consumer seems to be the blur.. I have an image with lots of blur-objects and its nearly impossible to work on this file on a 1.4ghz box even with blur quality set to lowest.
greetings, Florian Ludwig
Bill Baxter wrote:
... Is there a way to hide everything but the current selection? Or to use outline rendering for everything but the current selection? I was playing around with editing the about.svg splash screen and with all the blurring going on rendering was very slow when zoomed in. Outline mode fixed the speed, but then it's hard to tell what the current thing I'm editing really looks like. Anyway more flexible control over the rendering quality seems like it would be useful. An intermediate between outline and full would be nice too. It would basically turn off expensive effects like blur and just do a simple color rendering.
Have you tried setting the filter quality lower? (It's in the Inkscape preferences.) That should help, it doesn't turn blur off, but it does make it considerably less expensive.
On 4/4/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Bill Baxter wrote:
... Is there a way to hide everything but the current selection? Or to use outline rendering for everything but the current selection? I was playing around with editing the about.svg splash screen and with all the blurring going on rendering was very slow when zoomed in. Outline mode fixed the speed, but then it's hard to tell what the current thing I'm editing really looks like. Anyway more flexible control over the rendering quality seems like it would be useful. An intermediate between outline and full would be nice too. It would basically turn off expensive effects like blur and just do a simple color rendering.
Have you tried setting the filter quality lower? (It's in the Inkscape preferences.) That should help, it doesn't turn blur off, but it does make it considerably less expensive.
No I haven't, but Florian replied earlier in the thread that it didn't make much difference even on the lowest quality setting. Anyway it's really something that should be handled on a situation by situation basis whereas app preferences are for modifying global behavior. If you have to change an app preference based on the document you're looking at then I think it indicates a UI problem.
Anyway, I'm just starting out using and inkscape, and I'm not even an artist so realistically this is not an issue for me. I was just suspecting that this was something that probably a lot of artists would want. I guess if an artist is making lots of heavyweight blurs the thing to do now is try to put those on separate layers and toggle visibility per layer. But that's probably easier said than done when a main use for blur is faking lighting and material properties -- meaning lots of composited layers. Not so easy to segregate the heavy parts out.
--bb
On Wed, Apr 04, 2007 at 05:32:35PM +0900, Bill Baxter wrote:
On 4/4/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Have you tried setting the filter quality lower? (It's in the Inkscape preferences.) That should help, it doesn't turn blur off, but it does make it considerably less expensive.
No I haven't, but Florian replied earlier in the thread that it didn't make much difference even on the lowest quality setting. Anyway it's really something that should be handled on a situation by situation basis whereas app preferences are for modifying global behavior. If you have to change an app preference based on the document you're looking at then I think it indicates a UI problem.
But it's not just a document-specific setting, it's a computer-specific setting. Just because your computer isn't fast enough to handle such-and-such an amount of blur in a document doesn't mean mine isn't, so it would be silly if we were sharing a document and we kept having to change the blur quality every time we sent the file between computers.
Of course, you're right that it changes according to situation too. Sometimes I'm drawing freehand with a tablet and need it to be snappy; sometimes I'm adjusting the blur in particular, or doing precision moves with the arrow keys, so I'd rather have it looking perfect and am willing to put up with a bit more latency.
It strikes me that the best solution would be that the user doesn't set the blur quality, but rather the amount of latency he's willing to put up with. Inkscape would monitor how laggy it's being and set the quality appropriately. Perhaps this could be integrated with the other quality settings as well, so that in the worst case Inkscape would just switch to outline mode. There would also be a menu-/key-bindable verb for "put it in high-quality" for those precision editing moments.
This is a bit of a heavy-duty feature, though, so I won't hold my breath, and I'm not even sure how useful it would be, particularly in the usual case where the designer's computer is up to the task of displaying the file in full, glorious Technicolor.
Am Mittwoch, den 04.04.2007, 11:26 +0100 schrieb Daniel Hulme:
On Wed, Apr 04, 2007 at 05:32:35PM +0900, Bill Baxter wrote:
On 4/4/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Have you tried setting the filter quality lower? (It's in the Inkscape preferences.) That should help, it doesn't turn blur off, but it does make it considerably less expensive.
No I haven't, but Florian replied earlier in the thread that it didn't make much difference even on the lowest quality setting. Anyway it's really something that should be handled on a situation by situation basis whereas app preferences are for modifying global behavior. If you have to change an app preference based on the document you're looking at then I think it indicates a UI problem.
But it's not just a document-specific setting, it's a computer-specific setting. Just because your computer isn't fast enough to handle such-and-such an amount of blur in a document doesn't mean mine isn't, so it would be silly if we were sharing a document and we kept having to change the blur quality every time we sent the file between computers.
I agree, the quality settings shoudn't be saved in the file. And those aren't saved there so its not an issue.
Of course, you're right that it changes according to situation too.
[...]
It strikes me that the best solution would be that the user doesn't set the blur quality, but rather the amount of latency he's willing to put up with. Inkscape would monitor how laggy it's being and set the quality appropriately. Perhaps this could be integrated with the other quality settings as well, so that in the worst case Inkscape would just switch to outline mode. There would also be a menu-/key-bindable verb for "put it in high-quality" for those precision editing moments.
Sounds like a really crazy/good idea to me. But also Bills idea of the "everything outlined but the selected"-toggle sounds great. Or even layer related quality settings might be worth.
Not sure want would be the "best" way or what would be "implementable" for the inkscape-devs. At least I can say the way its now - with the blur settings in the settings menu - I dont like since I like to change them "too" often. Perhaps just a "bad" habit from using xara.
Florian
Bill Baxter wrote:
On 4/4/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Bill Baxter wrote:
...
Have you tried setting the filter quality lower? (It's in the Inkscape preferences.) That should help, it doesn't turn blur off, but it does make it considerably less expensive.
No I haven't, but Florian replied earlier in the thread that it didn't make much difference even on the lowest quality setting. Anyway it's really something that should be handled on a situation by situation basis whereas app preferences are for modifying global behavior. If you have to change an app preference based on the document you're looking at then I think it indicates a UI problem.
That's a bit strong, on my system I have to have quite a lot of blur to have it become irritating (at least for my goals), so it's not that related to the document. It's more related to the machine than the document, or at the very least equally related. So what Inkscape could do is automatically adjust this global setting based on the measured performance of your system, but that could be quite complicated.
In addition, it's a very subjective area of course. For my purposes it's not a problem if redrawing the entire screen takes about a second, but if you move around a lot, zooming in, zooming out, panning, etc. then a second might seem like an eternity. So this is also a reason for having a setting that controls the trade-off between quality and speed.
Also, there are still some ways left to speed up blurring further (e.g. by doing the subsampling at an earlier stage, and I have an interesting idea about blurring polygons in a "smarter" way), but it will always remain a relatively expensive operation.
To reduce the problem further it could be interesting to experiment with alternate views like Outline mode, as I think was mentioned earlier, so if you have any suggestions, lets hear them.
BTW, if you feel the difference between Lowest and Best is not big enough, it's something that can be adjusted relatively easily (the image is just subsampled), so be sure to post an RFE or bug report. (The only problem is that it eventually becomes quite visible, although that problem could also be reduced a bit, but then it would become a bit slower again, it remains a trade-off.)
On 4/5/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
BTW, if you feel the difference between Lowest and Best is not big enough, it's something that can be adjusted relatively easily (the image is just subsampled), so be sure to post an RFE or bug report. (The only problem is that it eventually becomes quite visible, although that problem could also be reduced a bit, but then it would become a bit slower again, it remains a trade-off.)
I think I would join this request. In my experience, I would like the lower steps of the scale to be rougher and faster still.
On 4/3/07, Bill Baxter <wbaxter@...155...> wrote:
Love the python scripting too. Can't wait to start tinkering with it. I have done a bit of research on manipulating drawings and have plans for more things. (http://www.cavie-x.net/doodle/) It might be nice to implement future things as Inkscape Python scripts or perhaps more full-fledged plugins.
I like the idea of spray-painting with randomized steps from a path interpolation. I added this to the corresponding RFE:
http://sourceforge.net/tracker/index.php?func=detail&aid=908792&grou...
Stroke patterns seem to be limited to axis-aligned textures? Is there any way to transform the pattern applied to the stroke, at least in global coordinates?
Looks like a bug. Fill patterns show handles but stroke handles do not. Can you please submit it to the bug tracker?
It would also be nice to be able to apply a texture in a curvilinear coordinate system relative to the stroke itself, with x being the direction tangent to the stroke, and y perpendicular to it. Being able to do curve-relative mappings opens the door to lots of possibilities. Like Hsu's "Skeletal Strokes" (which I see someone has already noted on the wiki: http://wiki.inkscape.org/wiki/index.php/Expression)
Try the Pattern along Path effect
Why are spirals and stars top level tools? Seems very odd to have two such niche items on the main toolbar. Are they actually used that often? Why not gears or block arrows or speech bubbles or ... etc.
Gears and bubbles are not simple geometric figures. Stars and spirals are.
I'm curious about the choice of usage for Tab and Space keys. Space as select tool toggle is reasonable, since that is pretty frequently used. Still, seems to me like Photoshop's hold-toggle for canvas panning is a better option (i.e. needed more frequently), but easy access to the selection tool is also nice.
Panning the canvas is much easier by middle mouse button - no need to touch keyboard at all.
Actully, this has already been proposed many times by former Adobe users who are used to space-for-panning. My official stand on it always was: if someone implements this as an option (off by default), we will accept the patch. You need it, you code it :)
But Tab as "select next" seems like a waste of prime keyboard real estate. I don't see how this is useful once you have more than a dozen or so elements in your drawing. Some kind of hide/reveal function might be good for this.
I use Tab all the time. _Most_ real world drawings use a limited number of objects. And in complex drawings, you normally use grouping and layers, and Tab/Shift+Tab always select object within the current layer or group (if you entered the group, i.e. made it a temporary layer).
Is there a way to hide everything but the current selection? Or to use outline rendering for everything but the current selection?
Not at this time.
I was playing around with editing the about.svg splash screen and with all the blurring going on rendering was very slow when zoomed in. Outline mode fixed the speed, but then it's hard to tell what the current thing I'm editing really looks like.
Watch the selected style indicator in the statusbar. It's quite informative showing you at a glance the fill, stroke, and opacity of the selected object (though currently not blur). Textual description in the statusbar is also very useful.
On 4/5/07, bulia byak <buliabyak@...155...> wrote:
On 4/3/07, Bill Baxter <wbaxter@...155...> wrote:
Love the python scripting too. Can't wait to start tinkering with it. I have done a bit of research on manipulating drawings and have plans for more things. (http://www.cavie-x.net/doodle/) It might be nice to implement future things as Inkscape Python scripts or perhaps more full-fledged plugins.
I like the idea of spray-painting with randomized steps from a path interpolation. I added this to the corresponding RFE:
It's also a very interesting technique for animation (i.e. randomization + interpolation). I'm looking forward to how inkscape develops on that front.
If you haven't seen Takeo Igarashi's work on animation, it's very slick. http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/rigid/index.html this one's mostly 3D but the same concepts apply to 2D http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/squirrel/index.html
It would be great to see inkscape move in a direction like that.
Stroke patterns seem to be limited to axis-aligned textures? Is there any way to transform the pattern applied to the stroke, at least in global coordinates?
Looks like a bug. Fill patterns show handles but stroke handles do not. Can you please submit it to the bug tracker?
Ok, I'll try to repro exactly what the case was where it wasn't working and check here first that it's really a bug.
It would also be nice to be able to apply a texture in a curvilinear coordinate system relative to the stroke itself, with x being the direction tangent to the stroke, and y perpendicular to it. Being able to do curve-relative mappings opens the door to lots of possibilities. Like Hsu's "Skeletal Strokes" (which I see someone has already noted on the wiki: http://wiki.inkscape.org/wiki/index.php/Expression)
Try the Pattern along Path effect
Hmm, that just made an axis aligned texture along the path for me. So trying to apply a little pencil texture (approx 8px x 64px) to a previously drawn curve just resulted in a curve horizontally striped with my pencil texture. Maybe I wasn't using the right modes for Pattern along Path?
Why are spirals and stars top level tools? Seems very odd to have two such niche items on the main toolbar. Are they actually used that often? Why not gears or block arrows or speech bubbles or ... etc.
Gears and bubbles are not simple geometric figures. Stars and spirals are.
After going through the tutorials I see that "Stars" is something of a misnomer given the range of things you can do with a star. You can make a triangle toothed gear pretty easily with the star tool. Square toothed would be harder, but rounded teeth are no problem (Corners:20, Spoke Ratio:0.85, Rounded:0.6).
Spirals on the other hand... well the tutorials didn't have much to say other than "these aren't as useful as stars". Anyway I think the approach taken by MSoffice (and probably others) makes sense. The idea being that some objects can benefit from having a few high-level adjustment handles. Inkskape's Cirlces,Rects,Stars and Spirals operate in this way, but there's basically an unlimited number of parameterized objects that could be useful.
It would be really cool to be able to create custom "rigged' objects similar to the built-in tools. Then things like speech bubbles and block arrows and all the other objects in MS office could be implemented as instances of that type. The idea of a handle that controls a parameter in turn controls a combination of attributes is very powerful. It's basically the thing that makes 3D animated movies like Shrek possible at all, but I think it could be just as useful in a 2D drawing package. The "parameters" can be anything. Even like a time value for an animation or a morph. Or whatever else you can imagine.
I'm curious about the choice of usage for Tab and Space keys. Space as select tool toggle is reasonable, since that is pretty frequently used. Still, seems to me like Photoshop's hold-toggle for canvas panning is a better option (i.e. needed more frequently), but easy access to the selection tool is also nice.
Panning the canvas is much easier by middle mouse button - no need to touch keyboard at all.
My laptop doesn't have a middle button.
Actully, this has already been proposed many times by former Adobe users who are used to space-for-panning. My official stand on it always was: if someone implements this as an option (off by default), we will accept the patch. You need it, you code it :)
Oooh. That's encouraging. I'd like to look into it. I got the source compiling this morning. Is the basic infrastructure for handling temporary toggles in the input system there currently? That would be step one. Or actually... now that I think about it, step one would probably be to implement a grabbing hand tool, period, since there doesn't seem to be one.
But Tab as "select next" seems like a waste of prime keyboard real estate. I don't see how this is useful once you have more than a dozen or so elements in your drawing. Some kind of hide/reveal function might be good for this.
I use Tab all the time. _Most_ real world drawings use a limited number of objects. And in complex drawings, you normally use grouping and layers, and Tab/Shift+Tab always select object within the current layer or group (if you entered the group, i.e. made it a temporary layer).
I see. The tutorial also makes a good case for Tab, based on the fact after unselecting all it gives you an easy way to select the top object or the bottom object. I also noticed tab works for editing points on a curve. That's very nice to have.
Is there a way to hide everything but the current selection? Or to use outline rendering for everything but the current selection?
Not at this time.
I kinda like the way Flash handles recursive edits for this. If you double click on an object that is actually a named group the background washes out and you can see the thing you're working on clearly.
I was playing around with editing the about.svg splash screen and with all the blurring going on rendering was very slow when zoomed in. Outline mode fixed the speed, but then it's hard to tell what the current thing I'm editing really looks like.
Watch the selected style indicator in the statusbar. It's quite informative showing you at a glance the fill, stroke, and opacity of the selected object (though currently not blur). Textual description in the statusbar is also very useful.
I see. That is somewhat better than nothing at all. But it seems like it might be common to get just "unset" as the value there if you have lots of clones. (I was just trying the technique out on the "keys.svg" file).
Regards, --bb
On 4/4/07, Bill Baxter <wbaxter@...155...> wrote:
If you haven't seen Takeo Igarashi's work on animation, it's very slick. http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/rigid/index.html this one's mostly 3D but the same concepts apply to 2D http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/squirrel/index.html
Thanks for the interesting links. Using internal triangulation for more natural manipulation of paths is an idea that already occurred to me.
Try the Pattern along Path effect
Hmm, that just made an axis aligned texture along the path for me. So trying to apply a little pencil texture (approx 8px x 64px) to a previously drawn curve just resulted in a curve horizontally striped with my pencil texture. Maybe I wasn't using the right modes for Pattern along Path?
Not "Convert object to pattern", but Effects > Generate from Path > Pattern along Path:
http://inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png
Spirals on the other hand... well the tutorials didn't have much to say other than "these aren't as useful as stars".
Yet they are useful in design. I used them (at least) several times in real projects. And they are VERY hard to do manually unless you have a tool for them.
Panning the canvas is much easier by middle mouse button - no need to touch keyboard at all.
My laptop doesn't have a middle button.
Ctrl+right button works just as well. Ctrl+arrows are also very handy.
Actully, this has already been proposed many times by former Adobe users who are used to space-for-panning. My official stand on it always was: if someone implements this as an option (off by default), we will accept the patch. You need it, you code it :)
Oooh. That's encouraging. I'd like to look into it. I got the source compiling this morning. Is the basic infrastructure for handling temporary toggles in the input system there currently? That would be step one. Or actually... now that I think about it, step one would probably be to implement a grabbing hand tool, period, since there doesn't seem to be one.
A separate tool is not _really_ necessary - IMHO it will be just a waste of precious toolbar space. But it's just an IMHO, maybe we'll have to have it just to look more friendly to Adobe refuges. But, separate tool or not, the functionality itself must be in event-context.cpp which is the superclass of all event contexts (tools), so that it can be done in any tool without actual switching the tool internally (even though it may _look_ like tool switching to the user). The reason for that is that switching a tool is expensive - it means destroying the old event context object and instantiating a new one, and what's worse, it loses tool state and tool-specific selection (such as text selection in text tool or selected nodes in Node tool), and also removes the screen handles of the old tool which redraws parts of the screen and may be slow in complex documents. So, the processing of Space and the panning code must all be in event-context.cpp, so that each event context has its own copy of the code and can pan on Space without switching away from the current tool. (By the way the middle-click and ctrl+arrow panning is also in event-context.cpp, for the same reasons.) Whether we'll also get a new top-level tool button for Hand and whether the UI should show its button depressed on Space (which would necessarily be "fake" because the tool will not be actually switched) is up to the implementor; I would prefer to not have the tool button, but if we do have it, to not have it pressed when you press Space in another tool.
By the way, the same reasoning applies to our Dropper tool which is used for picking a color from the drawing. It is currently a separate tool, but it is most often used from within other tools, so this is inconvenient for all the same reasons (slow switch, losing selection, etc). So the current plan is to move the corresponding code from dropper-context.cpp to event-context.cpp and make it work in all tools (upon pressing F7) without switching. The Dropper tool button and context will likely remain, but it will just use the code from event-context parent. If you are interested in helping out, this might be a good next project after you implement the Space-panning :)
Watch the selected style indicator in the statusbar. It's quite informative showing you at a glance the fill, stroke, and opacity of the selected object (though currently not blur). Textual description in the statusbar is also very useful.
I see. That is somewhat better than nothing at all. But it seems like it might be common to get just "unset" as the value there if you have lots of clones. (I was just trying the technique out on the "keys.svg" file).
If you're working with clones, yes. But then just press Shift+D to jump to the original and see its style (which will be the style of the clone as well).
On 4/5/07, bulia byak <buliabyak@...155...> wrote:
On 4/4/07, Bill Baxter <wbaxter@...155...> wrote:
If you haven't seen Takeo Igarashi's work on animation, it's very slick. http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/rigid/index.html this one's mostly 3D but the same concepts apply to 2D http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/squirrel/index.html
Thanks for the interesting links. Using internal triangulation for more natural manipulation of paths is an idea that already occurred to me.
Actually you don't even really need the triangulation to get that sort of effect. Schaefer presented a method based on Moving Least Squares at the last Siggraph that gets pretty similar results without the need for triangulating. I have an implementation I wrote (in D) if anyone is interested. But the basic technique is not that complicated to implement going straight from the paper. Just a little bit of linear algebra. http://faculty.cs.tamu.edu/schaefer/research/mls.pdf
Try the Pattern along Path effect
Hmm, that just made an axis aligned texture along the path for me. So trying to apply a little pencil texture (approx 8px x 64px) to a previously drawn curve just resulted in a curve horizontally striped with my pencil texture. Maybe I wasn't using the right modes for Pattern along Path?
Not "Convert object to pattern", but Effects > Generate from Path > Pattern along Path:
http://inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png
All those examples are of a vector objects being applied along a path. I'm trying to apply a _pattern_ along a path. The fact that we're having this misunderstanding says to me that the "Pattern along Path" is a poor choice of name, because what it means by "Pattern" is not what the rest of Inkscape means by "Pattern". "Stroke Path with Object" might be a better choice of name.
But anyway,...
Is it possible to do something like the following: * File->Import... (choose image) * Object->Pattern->Objects to Pattern * Select new pattern filled rect * Select curve * Effects->Generate From Path->Pattern Along Path
Doesn't seem to work to me. The pattern (that is, texture -- a "Pattern" in the inkscape sense) doesn't re-orient to follow the direction of the stroke.
Spirals on the other hand... well the tutorials didn't have much to say other than "these aren't as useful as stars".
Yet they are useful in design. I used them (at least) several times in real projects. And they are VERY hard to do manually unless you have a tool for them.
Yeh, ok. I can believe you. But I also think there are plenty of other shapes that are as common or moreso. So it suggests to me rect/circle/star/spiral should just be 4 particular instances of a larger class of 'parameterized objects'.
Panning the canvas is much easier by middle mouse button - no need to touch keyboard at all.
My laptop doesn't have a middle button.
Ctrl+right button works just as well. Ctrl+arrows are also very handy.
But that's definitely not as easy as Space+Left button.
[Snip]
Thanks for the detailed explanation of how and where to start implementing this.
By the way, the same reasoning applies to our Dropper tool which is used for picking a color from the drawing. It is currently a separate tool, but it is most often used from within other tools, so this is inconvenient for all the same reasons (slow switch, losing selection, etc). So the current plan is to move the corresponding code from dropper-context.cpp to event-context.cpp and make it work in all tools (upon pressing F7) without switching. The Dropper tool button and context will likely remain, but it will just use the code from event-context parent. If you are interested in helping out, this might be a good next project after you implement the Space-panning :)
Hmm what I noticed with middle button panning and sounds like with the eye-dropper idea is the lack of visual feedback. You don't see any change in the cursor to indicate you've changed modes.
--bb
On 4/5/07, Bill Baxter <wbaxter@...155...> wrote:
Thanks, that's very interesting. If we could implement something like that for path editing in Inkscape it would be very useful.
http://inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png
All those examples are of a vector objects being applied along a path. I'm trying to apply a _pattern_ along a path. The fact that we're having this misunderstanding says to me that the "Pattern along Path" is a poor choice of name, because what it means by "Pattern" is not what the rest of Inkscape means by "Pattern". "Stroke Path with Object" might be a better choice of name.
OK, at some point we'll convert it from a Python effect to a built-in path effect, at which point we can revisit the issue of the name.
But anyway,...
Is it possible to do something like the following:
- File->Import... (choose image)
- Object->Pattern->Objects to Pattern
- Select new pattern filled rect
- Select curve
- Effects->Generate From Path->Pattern Along Path
Doesn't seem to work to me. The pattern (that is, texture -- a "Pattern" in the inkscape sense) doesn't re-orient to follow the direction of the stroke.
Objects to Pattern (unlike the effect) creates patterns that are defined in SVG and have no provisions for any kind of bending, only affine transforms. So I guess the answer is no. Still, I don't quite understand what you are trying to achieve by the above steps and why a simple Pattern Along Path (without Objects to Pattern) cannot do that. Can you make an illustration of the desired effect?
Yet they are useful in design. I used them (at least) several times in real projects. And they are VERY hard to do manually unless you have a tool for them.
Yeh, ok. I can believe you. But I also think there are plenty of other shapes that are as common or moreso.
Common and at the same time non-trivial to do with other existing tools? Can you give an example?
Hmm what I noticed with middle button panning and sounds like with the eye-dropper idea is the lack of visual feedback. You don't see any change in the cursor to indicate you've changed modes.
Certainly, cursor changing for panning is a good idea, and should be easy to add. One problem is that we use a standard move cursor in Selector tool when it's over an object, to indicate that the object can be dragged, so using the same cursor for panning would be confusing. We need to disambiguate these two cursors somehow (but ideally, by still using some stock cursors - not custom - because both these actions are really basic).
On 4/6/07, bulia byak <buliabyak@...155...> wrote:
But anyway,...
Is it possible to do something like the following:
- File->Import... (choose image)
- Object->Pattern->Objects to Pattern
- Select new pattern filled rect
- Select curve
- Effects->Generate From Path->Pattern Along Path
Doesn't seem to work to me. The pattern (that is, texture -- a "Pattern" in the inkscape sense) doesn't re-orient to follow the direction of the stroke.
Objects to Pattern (unlike the effect) creates patterns that are defined in SVG and have no provisions for any kind of bending, only affine transforms. So I guess the answer is no. Still, I don't quite understand what you are trying to achieve by the above steps and why a simple Pattern Along Path (without Objects to Pattern) cannot do that. Can you make an illustration of the desired effect?
http://www.antigrain.com/demo/line_patterns.gif
All of those lines were created by sweeping a _raster image_ along the path. That's what I'm after. Now I'll admit that in those specific cases they all look like they could be done equally well by sweeping a vector object along the path. But that's not always so easy if what you want to sweep along the path is some kind of noisy natural texture, for instance. In particular I was trying to apply a scanned image of a pencil line to try to make lines that look more like they were drawn by a pencil.
Yet they are useful in design. I used them (at least) several times in real projects. And they are VERY hard to do manually unless you have a tool for them.
Yeh, ok. I can believe you. But I also think there are plenty of other shapes that are as common or moreso.
Common and at the same time non-trivial to do with other existing tools? Can you give an example?
I think what you're not getting here is that "common" is in the eye of the beholder. I can't see myself ever needing that spiral tool. I do however frequently need block arrows, but keeping them symmetric while adjusting the length, width, pitch of the arrow head, etc is a pain. If I were a designer of clockwork mechanisms I'd like to have a star-like tool for making gear wheels. If I were a cartoon maker I'd like to have speech bubbles where the roundedness and location and length of the pointer part were easily modifiable. If I were a flow-chart maker I'd like to have presets for all the common flow chart symbols If I made greeting cards I might like to have parameterized heart-shaped objects If I made database process charts I might like to have a parameterized barrel-type shapes If I made qbert landscapes I might like to have a way to make a perspective cube without assembling it from three distorted squares.
Etc. So ultimately all that I'm saying is that it would be nice if there were an easy way to create new parameterized objects besides the stock four (circle,square,star,spiral).
--bb
On 4/5/07, Bill Baxter <wbaxter@...155...> wrote:
This is exactly what Pattern along Path is great at. No need for Objects to Pattern.
All of those lines were created by sweeping a _raster image_ along the path. That's what I'm after.
If you pnly have a raster, it's much easier to trace it to vector and then use Pattern along Path. Vectorizing it has other advantages too.
Now I'll admit that in those specific cases they all look like they could be done equally well by sweeping a vector object along the path. But that's not always so easy if what you want to sweep along the path is some kind of noisy natural texture, for instance. In particular I was trying to apply a scanned image of a pencil line to try to make lines that look more like they were drawn by a pencil.
Try Calligraphic pen with high Tremor.
I think what you're not getting here is that "common" is in the eye of the beholder. I can't see myself ever needing that spiral tool. I do however frequently need block arrows, but keeping them symmetric while adjusting the length, width, pitch of the arrow head, etc is a pain.
Note that I said "not trivial to do with existing tools." Creating all sorts of axially symmetric shapes is quite trivial by using clones.
If I were a designer of clockwork mechanisms I'd like to have a star-like tool for making gear wheels.
Agreed, but this would be better as a mode of the Star tool, not as a new tool.
If I were a cartoon maker I'd like to have speech bubbles where the roundedness and location and length of the pointer part were easily modifiable.
Again, trivial to do with existing tools. By the way randomized and rounded stars make pretty good bubbles.
If I were a flow-chart maker I'd like to have presets for all the common flow chart symbols
And we do have that, see Connector tool and the markers in Stroke Style tab in Fill and Stroke.
If I made greeting cards I might like to have parameterized heart-shaped objects
I rather doubt that. If you want your cards to have a human touch, more likely you would want a good freehand drawing tool for naturalistic strokes, and our Calligraphy pen provides exactly that.
If I made database process charts I might like to have a parameterized barrel-type shapes If I made qbert landscapes I might like to have a way to make a perspective cube without assembling it from three distorted squares.
These we will hopefully have at the end of this summer with the 3D Box tool, see http://www.rzuser.uni-heidelberg.de/~malbert/.
So ultimately all that I'm saying is that it would be nice if there were an easy way to create new parameterized objects besides the stock four (circle,square,star,spiral).
And what is not easy about looking up e.g. sp-star.cpp and star-context.cpp and modifying them for your own kind of object? There's not much there, most of the code is the pure logic of the shape itself. Admittedly, it can probably be made simpler still, but it's not like we have long queues of developers wishing to create new object types :) For example, for the 3D tool, 99% of the work will be figuring out the math and finding the best behavior of its operation; inserting it into Inkscape will be the easy part.
On 4/6/07, bulia byak <buliabyak@...155...> wrote:
Ok Bulia, I'm glad to hear that it is not difficult to create new parameterized object types by modifying cpp files and that you agree that such a capability is valuable. Requiring .cpp manipulations kind of limits the number of artists who are likely unleash their creativity in this arena however.
So I think the logical progression if you want to tap into the creativity out there would be to make a system such that new parameterized objects could separate components. As something like plugins or extensions. And preferably it wouldn't require any c++ coding.
-- Ok, so spirals and gear wheels etc are great and all. Nice and simple. But the concept of a parameterized object is very general. Think of it as a generic function. You give it a number and it gives you some paths. What happens in between could be *anything*. And of course it doesn't have to be just one number as input. For a rectangle right now now the numbers are things like x-corner radius and y-corner radius and the output is a path representing a rounded rectangle. But the relationship can be anything. You could have an 'interpolation object' for instance, where the input is a value between 0 and 1 and the output is a blend between two inputs. You could make a skeleton-based 2D human character where the input is joint angles and the output is a set of paths that define a 'nice' silhouette to go with those angles (there are various ways to do this from the 3D world by applying weighted combinations of the bone transforms to nearby vertexes).
Those things are useful by themselves just for creating flexible objects, but they become even more useful once you start animating things, at least if you allow any parameter to become a function of time.
You can also start to think of deformation and modification operations as things that operate on a base object according to some input parameters. For example a perspective transform is just a transformation with 8 (I think!) scalar inputs that define the transform. Such a transform can be applied to the underlying object and the parameters forgotten about, or the parameters can be kept and the transformation goes onto the underlying objects "modifier stack". That object + modifier combo can itself be thought of as just another parameterized object.
-- All this is probably way off future crazy talk, I know. But it helps to have some idea of where you'd like to go eventually. I was hopeful that the inkscape devs would be amenable to such ideas (or already planning such things themselves). If not then that's ok too. To be honest I'm really just trying to feel out how strong the development team behind inkscape really is, because it seems like a very well thought out tool, and the bits of implementation I've looked at seem nice, and folks on the lists have been really helpful so far too. It has all exceeded my expectations for the most part up to this point. If it really is backed by a solid dev team with good leadership then (and here's where the selfish motivation comes in) I think it could make a very nice platform for my future research endeavors. But if you guys and I don't see eye to eye on things like a basic vision for the future and basic usability concepts then I'm probably barking up the wrong tree, and better off sticking with my own half-assed vector drawing platform I wrote using AGG.
Either way I don't see me giving up inkscape as an end-user tool. It's quite nice :-) I'll definitely be using it for all my vector drawing needs for the forseeable future.
--bb
On 4/5/07, Bill Baxter <wbaxter@...155...> wrote:
So I think the logical progression if you want to tap into the creativity out there would be to make a system such that new parameterized objects could separate components. As something like plugins or extensions. And preferably it wouldn't require any c++ coding.
Everithing is possible. It's only a question of priorities. If this is important for you, and if you come up with a viable plan for a generic parametrized shape tool, including a UI which allows the user to express the "anything" part that you stress in a way that is significantly simpler than C++ coding, then no one would object to your working on it and we will help you in every way we can. I'm just saying that for me personally, other things have higher priority at this time.
And we would really hate to lose you as a contributor simply because we refuse to drop the Spiral tool :)
You can also start to think of deformation and modification operations as things that operate on a base object according to some input parameters. For example a perspective transform is just a transformation with 8 (I think!) scalar inputs that define the transform. Such a transform can be applied to the underlying object and the parameters forgotten about, or the parameters can be kept and the transformation goes onto the underlying objects "modifier stack". That object + modifier combo can itself be thought of as just another parameterized object.
And that, or at least something similar to it, is also in the works. It's called Path Effects. We can use your help with it, too.
participants (6)
-
Bill Baxter -
bulia byak -
Daniel Hulme -
Florian Ludwig -
Jasper van de Gronde -
Jon A. Cruz