Hi,
is there a way to assign hot keys to specific actions in Inkscape instead of specific menu entries?
I often need to center objects horizontally and vertically and it would be a massive timesaver if I could simply use hot keys, maybe even one hot key for both actions (applied successively)?
I checked through the keybindings settings and the wiki, but failed to find an info.
Keep up the good wirk,
- Stellaris
On Tue, Nov 07, 2006 at 03:00:05PM +0100, Thorsten wrote:
Hi,
is there a way to assign hot keys to specific actions in Inkscape instead of specific menu entries?
I often need to center objects horizontally and vertically and it would be a massive timesaver if I could simply use hot keys, maybe even one hot key for both actions (applied successively)?
I checked through the keybindings settings and the wiki, but failed to find an info.
Have you tried editing /usr/share/inkscape/ui/keybindings.rc?
Bryce
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Have you tried editing /usr/share/inkscape/ui/keybindings.rc?
Bryce, the file to edit for remapping keys is called share/keys/default.xml. I'm not sure what the rc file is and whether it works at all, but in any case it's both a subset and a confusing duplication of keys/* files, and so I think it should be better removed.
(By the way, another annoying duplication is units.txt/xml. Bryce, can you please remove the one which is not enabled currently?)
However, while keys/default.xml file gives you a lot of freedom, you cannot assign just any action to any key, yet. This file only affects global actions. Some commands in Inkscape are not made global actions yet (such as centering) so you can't bind them to keys. All global actions (even those that are not assigned any keys by default) are listed in that file and can be reassigned. Read the comments in that file for more info.
Hi bulia,
<SNIP> Some commands in Inkscape are not made global actions yet (such as centering) so you can't bind them to keys. All global actions (even those that are not assigned any keys by default) are listed in that file and can be reassigned. Read the comments in that file for more info.
Thanks for the (indirect) verification that it's currently not possible to just edit a configuration file and be off with centering.
- Thorsten
On Tue, Nov 07, 2006 at 02:05:50PM -0400, bulia byak wrote:
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Have you tried editing /usr/share/inkscape/ui/keybindings.rc?
Bryce, the file to edit for remapping keys is called share/keys/default.xml.
Can you put a note about this into the Tips and Tricks tutorial or the Keys document? I had checked those for info about this before replying but didn't see anything there. (Thus why I posed it as a question instead of a statement.)
(By the way, another annoying duplication is units.txt/xml. Bryce, can you please remove the one which is not enabled currently?)
Well, units.xml was something Jon Cruz started after I implemented the units stuff using the units.txt file. The units.txt file is pretty easy to edit and has worked adequately, but I can see why some people might want it in xml. Unfortunately, the units.xml stuff never actually worked, and it wasn't clear what the plan was for making it work, so it's just been there disabled all this time.
Anyway, so since no further work's been done in the units.xml direction, I guess it can be dropped... Attached is a patch that should do it.
Unfortunately I haven't been able to get a successful build of inkscape on either of my machines for a few weeks, so can't easily test it. (I get messages about issues with extensions, missing keys/default.xml, etc. and just haven't had time to investigate) Could you apply this patch and see if it doesn't break anything (check the units in the transform dialog), and commit it if so?
However, while keys/default.xml file gives you a lot of freedom, you cannot assign just any action to any key, yet. This file only affects global actions. Some commands in Inkscape are not made global actions yet (such as centering) so you can't bind them to keys. All global actions (even those that are not assigned any keys by default) are listed in that file and can be reassigned. Read the comments in that file for more info.
Then would it be possible to have a shortcut key that does vertical and horizontal center alignment? This tends to be one of the most common kinds of alignment, so if it had a shortcut key, it would reduce how often one has to have the align dialog open, which would trim a bit of visual clutter.
Fwiw, in my own personal use, where I run into this the most is for centering text on boxes. In most programs it's possible to edit text on a box and have it automatically be aligned and centered in the shape, so as you edit it, it always stays correct, however in Inkscape there is no such capability, so you have to manually re-center stuff a lot, thus (I think) the desire for having a shortcut key to do this.
Oh, there is also a bug in text centering - write some text, then change it from left-aligned to center-aligned. The text then moves from its current position to half its width to the left. This bug has been there since Sodipodi days...
Bryce
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Bryce, the file to edit for remapping keys is called share/keys/default.xml.
Can you put a note about this into the Tips and Tricks tutorial or the Keys document?
OK, I will add a note.
As for the .rc file, would anyone object if I just delete it? It doesn't look like it's being used.
Well, units.xml was something Jon Cruz started after I implemented the units stuff using the units.txt file. The units.txt file is pretty easy to edit and has worked adequately, but I can see why some people might want it in xml. Unfortunately, the units.xml stuff never actually worked, and it wasn't clear what the plan was for making it work, so it's just been there disabled all this time.
JonCruz, will you object to removing units.xml?
Then would it be possible to have a shortcut key that does vertical and horizontal center alignment?
What needs to be done is creating a _verb_ that does this. After that, adding it to menu or assigning a key to it will be trivial. There are many things that Inkscape can do in principle, but not through a verb, and these things should be verbified. By the way, verbification is pretty simple thing to do, so it's a good work for novice coders. Just review verbs.h and verbs.cpp, they're pretty self-explanatory.
For example just recently, I verbified the select next/select prev actions, bound to Tab/Shift+Tab, and as a result these keys now work in all tools and not only Selector/Node as before.
Oh, there is also a bug in text centering - write some text, then change it from left-aligned to center-aligned. The text then moves from its current position to half its width to the left. This bug has been there since Sodipodi days...
It's not really a "bug". Inkscape just needs to recalculate the anchor point based on the bounding box of the text, in addition to changing alignment. More like a missing feature (worth a RFE).
On Tue, Nov 07, 2006 at 04:20:31PM -0400, bulia byak wrote:
As for the .rc file, would anyone object if I just delete it? It doesn't look like it's being used.
No objection from me. Looks like I was the one who added it originally, and no one else has done anything with it.
By the way, verbification is pretty simple thing to do, so it's a good work for novice coders. Just review verbs.h and verbs.cpp, they're pretty self-explanatory.
For example just recently, I verbified the select next/select prev actions, bound to Tab/Shift+Tab, and as a result these keys now work in all tools and not only Selector/Node as before.
Hmm, could you provide a bit more detail? verbs.h looks straightforward enough, but looking at verbs.cpp it'd take a bit of time to nut out what would need to be done there.
I've been thinking that we should give added visibility to areas like this where novice coders could quite easily get involved and make a difference to the codebase. I know there are a large number of people who would like to help but who are not confident in being able to code. So tasks like this that can quite easily be boiled down to sort of a 'paint by numbers' procedure could be things we may be able to farm out more, like we've been able to successfully do with translations.
Maybe just explain what steps were involved in doing the select action changes you did, along with any tips on things to watch out for?
Bryce
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Hmm, could you provide a bit more detail? verbs.h looks straightforward enough, but looking at verbs.cpp it'd take a bit of time to nut out what would need to be done there.
OK, here's an illustrated guide:
First, add IDs for new verbs to verbs.h:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/verbs.h?r1=132...
The place of the ID in the list determines to which group it belongs (EditVerbs, FileVerbs, etc) - however, this is pretty arbitrary, so don't sweat if you can't find a perfect group for your verb, just use whichever makes most sense.
Then in verbs.cpp, fill in the verb structure with the name, description, action ID, etc; also in the same file, write the actual commands that the verb will do, in a switch case in one of ::perform methods:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/verbs.cpp?r1=1...
As you see, these verbs do different things depending on which tool you are in. Before verbification, this was coded into tool context files, and now we can remove that:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/node-context.c... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/select-context... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/draw-context.c... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/draw-context.c...
(the last one required writing two functions that will be called by the verb).
Now assign the keys to the newly created verbs:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/keys/inkscap...
and then copy inkscape.xml to default.xml.
Note: even if you are not assigning any key, you MUST list the new verb in inkscape.xml, using a <bind> without a key. Not only this file is a keymap, but it's also a reference for keymap writers, so it must have all verbs, assigned or not.
If you added a shortcut which didn't exist before, update also doc/keys.xml.
If you want the new verb in the menu, edit menus-skeleton.cpp and insert it there in an appropriate place.
Also review the other keymaps to see if you can assign the new verb to some key that would make sense. So in adobe-illustrator.xml, I assigned the new verbs to Alt+Ctrl+[], which seems to be the same thing according to the comments:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/keys/adobe-i...
Finally update the release notes:
http://wiki.inkscape.org/wiki/index.php?title=ReleaseNotes045&diff=8842&...
Ask me if you have any questions.
On Tue, Nov 07, 2006 at 10:18:31PM -0400, bulia byak wrote:
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Hmm, could you provide a bit more detail? verbs.h looks straightforward enough, but looking at verbs.cpp it'd take a bit of time to nut out what would need to be done there.
OK, here's an illustrated guide:
Cool, this is perfect! I've turned it into a wiki page here:
http://wiki.inkscape.org/wiki/index.php/AddingInterfaceVerbs
It would be nice to have one or two novice coders have a shot at this process and see if any clarification is needed. Anyone up to giving it a shot? My guess is there may be some uncertainty in how to figure out the changes to verbs.cpp.
Bryce
First, add IDs for new verbs to verbs.h:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/verbs.h?r1=132...
The place of the ID in the list determines to which group it belongs (EditVerbs, FileVerbs, etc) - however, this is pretty arbitrary, so don't sweat if you can't find a perfect group for your verb, just use whichever makes most sense.
Then in verbs.cpp, fill in the verb structure with the name, description, action ID, etc; also in the same file, write the actual commands that the verb will do, in a switch case in one of ::perform methods:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/verbs.cpp?r1=1...
As you see, these verbs do different things depending on which tool you are in. Before verbification, this was coded into tool context files, and now we can remove that:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/node-context.c... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/select-context... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/draw-context.c... http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/draw-context.c...
(the last one required writing two functions that will be called by the verb).
Now assign the keys to the newly created verbs:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/keys/inkscap...
and then copy inkscape.xml to default.xml.
Note: even if you are not assigning any key, you MUST list the new verb in inkscape.xml, using a <bind> without a key. Not only this file is a keymap, but it's also a reference for keymap writers, so it must have all verbs, assigned or not.
If you added a shortcut which didn't exist before, update also doc/keys.xml.
If you want the new verb in the menu, edit menus-skeleton.cpp and insert it there in an appropriate place.
Also review the other keymaps to see if you can assign the new verb to some key that would make sense. So in adobe-illustrator.xml, I assigned the new verbs to Alt+Ctrl+[], which seems to be the same thing according to the comments:
http://svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/keys/adobe-i...
Finally update the release notes:
http://wiki.inkscape.org/wiki/index.php?title=ReleaseNotes045&diff=8842&...
Ask me if you have any questions.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 11/8/06, Bryce Harrington <bryce@...983...> wrote:
Cool, this is perfect! I've turned it into a wiki page here:
http://wiki.inkscape.org/wiki/index.php/AddingInterfaceVerbs
Thanks!
A couple words on what might be good candidates for verbification:
- anything that all tools do but which is still not a verb, such as Esc for deselection
- anything that is needed for more complete keymaps emulating other editors, for example as listed here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1532158&gro...
- any global action (i.e. which is not limited to some tool's context) for which it just makes sense to have a quick shortcut, even if it is already available via a dialog, a tool control, or some other more complicated way (example: centering selected objects; increasing/decreasing blur/opacity/stroke width in selection, etc.).
On Wed, Nov 08, 2006 at 04:57:02AM -0400, bulia byak wrote:
On 11/8/06, Bryce Harrington <bryce@...983...> wrote:
Cool, this is perfect! I've turned it into a wiki page here:
http://wiki.inkscape.org/wiki/index.php/AddingInterfaceVerbs
Thanks!
A couple words on what might be good candidates for verbification:
- anything that all tools do but which is still not a verb, such as
Esc for deselection
- anything that is needed for more complete keymaps emulating other
editors, for example as listed here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1532158&gro...
- any global action (i.e. which is not limited to some tool's context)
for which it just makes sense to have a quick shortcut, even if it is already available via a dialog, a tool control, or some other more complicated way (example: centering selected objects; increasing/decreasing blur/opacity/stroke width in selection, etc.).
Got it. Feel free to add more ideas to that page.
Bryce
On Tue, 7 Nov 2006, bulia byak wrote:
On 11/7/06, Bryce Harrington <bryce@...983...> wrote:
Have you tried editing /usr/share/inkscape/ui/keybindings.rc?
Bryce, the file to edit for remapping keys is called share/keys/default.xml. I'm not sure what the rc file is and whether it works at all, but in any case it's both a subset and a confusing duplication of keys/* files, and so I think it should be better removed.
(By the way, another annoying duplication is units.txt/xml. Bryce, can you please remove the one which is not enabled currently?)
However, while keys/default.xml file gives you a lot of freedom, you cannot assign just any action to any key, yet. This file only affects global actions. Some commands in Inkscape are not made global actions yet (such as centering) so you can't bind them to keys. All global
The menu item all have actions setup, and there are a few items which have actions available but do not have menu items.
I'm a little suprised Bulia created a menu item for mode toggling instead of just creating the action, but I suppose everyone always wants to draw more attention to new features.
I guess the best thing for Thorsten to do is file a request for more actions (or if possible submit a patch).
I've already files a request for more actions (Zoom in particular) which is necessary to better meet the expectations of Macromedia users: [ 1532158 ] more actions to help with Freehand compatibility https://sourceforge.net/tracker/index.php?func=detail&aid=1532158&gr...
I'm sure there are many other things which it would be great to have actions for but that we would never have enough room to have menu items for them all.
actions (even those that are not assigned any keys by default) are listed in that file and can be reassigned. Read the comments in that file for more info.
Sincerely
Alan Horkan
On Wed, Nov 08, 2006 at 03:29:05PM +0000, Alan Horkan wrote:
I guess the best thing for Thorsten to do is file a request for more actions (or if possible submit a patch).
I've already files a request for more actions (Zoom in particular) which is necessary to better meet the expectations of Macromedia users: [ 1532158 ] more actions to help with Freehand compatibility https://sourceforge.net/tracker/index.php?func=detail&aid=1532158&gr...
I'm sure there are many other things which it would be great to have actions for but that we would never have enough room to have menu items for them all.
We now have a documented process for adding new actions:
http://wiki.inkscape.org/wiki/index.php/AddingInterfaceVerbs
Please collect requests for more actions and add them to the end of this page, with any appropriate references.
If anyone would like to take a shot at implementing verbs, go for it! :-)
Bryce
G'day,
(Please have a look at the attached SVG, and/or screenshot and then this email might make more sense).
I was trying to draw a glassy-look button. I took two spherical buttons, and tried to replicate a rectangle in the middle with the same shading and top/bottom border.
Like this: o=o Except the rectangle (=) occluded half of each spehere (o).
One feature I really needed during this process was a "make same width" button. I zoomed in, stretching the objects to exact-as-possible with mouse movements. However this was not an *exact* sizing. One side was easy, since I could align everything left, but the opposite side was just judged best fit.
After all this, I zoomed back out to see my button rendered with two distinct lines at the edge of the rectangle (at each end). As I zoomed back in to try and work out the problem, sometimes they'd disappear at different zoom intervals.
Eventually I worked out that it's some kind of rendering error. I even hand-edited the XML to ensure the rectangular layers were in exactly the same positions and widths... I still got the problem.
Any suggestions on how to work around this? It's apparent on exported bitmaps too.
Any comments on "Make same width" / "Make same height" buttons? I think this would be cool.
thanks, -kt
PS> My apologies to the people on the list who don't like attachments. I tried to make them as small as possible.
--
Please consider our environment before printing this email.
WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.
It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.
Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.
Westpac Banking Corporation ABN 33 007 457 141.
On 11/8/06, Kinsley Turner <kingsleyturner@...994...> wrote:
One feature I really needed during this process was a "make same width" button.
Edit->Copy, Edit->Paste size->Paste Width
After all this, I zoomed back out to see my button rendered with two distinct lines at the edge of the rectangle (at each end). As I zoomed back in to try and work out the problem, sometimes they'd disappear at different zoom intervals.
That's a known problem of our renderer (as well as many other renderers). To avoid it, you can just union the two shapes so they become one shape. If this is not possible, just always add a small overlap where shapes meet. In SVN version, in some cases you can group the two objects and slightly blur the group to make the seam disappear (for example, with your button it will even look better with some blur).
I encountered a similar problem recently when I was trying to create a marginally complex, but mathematically proportionate drawing. I tried everything: snaps on, snaps off, alignment left, right, etc., but no matter what I did, the shapes didn't line up. Finally, I ended up doing most of the work manually: I computed the size of the related rectangles and offsets of the lines manually, then entered them using the x, y, width and height text fields.
I had done the original using OO in about 30 minutes using grid and snap, but I wasn't pleased with the export/import from oodraw into inkscape and I needed the output as SVG. It ended up taking me considerable time to do this in Inkscape because I couldn't get "exact" pixel snaps.
While I appreciate Inkscape's ability to be flexible for more free-hand or free-form artistic expression, I would like to see a way for it to not be quite so clever. If I have a 64x64 rectangle and I want to stack 6 of them in a stairstep fashion and have each one of them exactly 64 pixels apart (at least while I'm creating the original drawing so I have correct proportions once I resize as needed), I would have hoped there was an easy way to achieve this behavior in Inkscape.
Maybe there is a better way (I would hope!), but I couldn't find it. For future reference, I would love to hear about it. I was trying to design/draw a stained-glass window representation, but until I did the manual approach described above, I wasn't happy with the results.
Maybe this is part of the same root cause Kinsley is referring to.
Thanks in advance,
ast
On Thu, 2006-11-09 at 00:07, Kinsley Turner wrote:
G'day,
(Please have a look at the attached SVG, and/or screenshot and then this email might make more sense).
I was trying to draw a glassy-look button. I took two spherical buttons, and tried to replicate a rectangle in the middle with the same shading and top/bottom border.
Like this: o=o Except the rectangle (=) occluded half of each spehere (o).
One feature I really needed during this process was a "make same width" button. I zoomed in, stretching the objects to exact-as-possible with mouse movements. However this was not an *exact* sizing. One side was easy, since I could align everything left, but the opposite side was just judged best fit.
After all this, I zoomed back out to see my button rendered with two distinct lines at the edge of the rectangle (at each end). As I zoomed back in to try and work out the problem, sometimes they'd disappear at different zoom intervals.
Eventually I worked out that it's some kind of rendering error. I even hand-edited the XML to ensure the rectangular layers were in exactly the same positions and widths... I still got the problem.
Any suggestions on how to work around this? It's apparent on exported bitmaps too.
Any comments on "Make same width" / "Make same height" buttons? I think this would be cool.
thanks, -kt
PS> My apologies to the people on the list who don't like attachments. I tried to make them as small as possible.
--
Please consider our environment before printing this email.
WARNING - This email and any attachments may be confidential. If received in error, please delete and inform us by return email. Because emails and attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems, you must be cautious. Westpac cannot guarantee that what you receive is what we sent. If you have any doubts about the authenticity of an email by Westpac, please contact us immediately.
It is also important to check for viruses and defects before opening or using attachments. Westpac's liability is limited to resupplying any affected attachments.
This email and its attachments are not intended to constitute any form of financial advice or recommendation of, or an offer to buy or offer to sell, any security or other financial product. We recommend that you seek your own independent legal or financial advice before proceeding with any investment decision.
Westpac Institutional Bank is a division of Westpac Banking Corporation, a company registered in New South Wales in Australia under the Corporations Act 2001 (Cth). Westpac is authorised and regulated in the United Kingdom by the Financial Services Authority and is registered at Cardiff in the United Kingdom as Branch No. BR 106. Westpac operates in the United States of America as a federally chartered branch, regulated by the Office of the Comptroller of the Currency.
Westpac Banking Corporation ABN 33 007 457 141.
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
On 11/9/06, Andrew S. Townley <atownley@...16...> wrote:
While I appreciate Inkscape's ability to be flexible for more free-hand or free-form artistic expression, I would like to see a way for it to not be quite so clever. If I have a 64x64 rectangle and I want to stack 6 of them in a stairstep fashion and have each one of them exactly 64 pixels apart (at least while I'm creating the original drawing so I have correct proportions once I resize as needed), I would have hoped there was an easy way to achieve this behavior in Inkscape.
If I understand you correctly, there's a relatively easy way to achieve this. Just snap your shapes to the pixel grid and export at the default 90 dpi, and the result will have no antialiasing at all for vertical and horizontal edges (only diagonal).
On Thu, 2006-11-09 at 17:10, bulia byak wrote:
On 11/9/06, Andrew S. Townley <atownley@...16...> wrote:
While I appreciate Inkscape's ability to be flexible for more free-hand or free-form artistic expression, I would like to see a way for it to not be quite so clever. If I have a 64x64 rectangle and I want to stack 6 of them in a stairstep fashion and have each one of them exactly 64 pixels apart (at least while I'm creating the original drawing so I have correct proportions once I resize as needed), I would have hoped there was an easy way to achieve this behavior in Inkscape.
If I understand you correctly, there's a relatively easy way to achieve this. Just snap your shapes to the pixel grid and export at the default 90 dpi, and the result will have no antialiasing at all for vertical and horizontal edges (only diagonal).
It wasn't really an antialiasing problem, I don't think. It probably was a problem with me vs. the snap capabilities of Inkscape. I tried to use pixels for the grid and turned on, in various combinations, snap to grid and snap to object, but neither seemed to give me consistent results. I'd get positions of fractional pixels. I'm sure I just didn't know what I was doing...
Export wasn't really the issue. I wanted the original master as SVG so I could scale it to different sizes and then export as bitmaps, but I needed the various individual pieces to line up exactly in the original SVG.
I've pulled together some screenshots of a simple example and of part of what I was trying to do as SVG. In doing so, I noticed something that I hadn't noticed before. If you look closely at the lines in both pictures, the "touching" lines are thicker than the external lines. Ideally, I would've liked to have them the same, but in most cases, the image is small enough that you wouldn't notice it. I realize that you end up discussing "inside" vs. "outside" dimensions from a coordinate system point of view, so if you have one 64x64 box starting at (0,0) with a 1px stroke, that stroke should arguably be lines at pixels 0 & 64 in both the x and y directions. If you then positioned the second one at (0, 64), then I wouldn't expect the common line to be twice as wide, but it appears that is the case in the example (http://atownley.org/wip/grid-snap-example.jpg). I've positioned the set on the right as accurately as I could using the x, y, w & h parameters. On the left, this was as close as I could get them to snap with the default settings.
Maybe I'm just confused on how it is supposed to work, but any comments/suggestions would be appreciated. BTW, I love Inkscape and I'm not trying to be over-critical. I'm just trying to figure out how to get the results I expect as efficiently as possible.
Thanks in advance,
ast
Oh, the shot of what I was really trying to achieve is here: http://atownley.org/wip/sg-example1.jpg.
Andrew S. Townley wrote:
... I've pulled together some screenshots of a simple example and of part of what I was trying to do as SVG. In doing so, I noticed something that I hadn't noticed before. If you look closely at the lines in both pictures, the "touching" lines are thicker than the external lines. Ideally, I would've liked to have them the same, but in most cases, the image is small enough that you wouldn't notice it. I realize that you end up discussing "inside" vs. "outside" dimensions from a coordinate system point of view, so if you have one 64x64 box starting at (0,0) with a 1px stroke, that stroke should arguably be lines at pixels 0 & 64 in both the x and y directions. If you then positioned the second one at (0, 64), then I wouldn't expect the common line to be twice as wide, but it appears that is the case in the example (http://atownley.org/wip/grid-snap-example.jpg). I've positioned the set on the right as accurately as I could using the x, y, w & h parameters. On the left, this was as close as I could get them to snap with the default settings. ...
It might snap the bounding box of the line instead of the nodes of the line. So try to set on snapping of points and position the nodes using the node editor.
(BTW, in any case, the x, y, w and h values take the stroke of the line into account.)
On Fri, 2006-11-10 at 09:10, Jasper van de Gronde wrote:
Andrew S. Townley wrote:
... (http://atownley.org/wip/grid-snap-example.jpg). I've positioned
the
set on the right as accurately as I could using the x, y, w & h parameters. On the left, this was as close as I could get them to
snap
with the default settings. ...
It might snap the bounding box of the line instead of the nodes of the line. So try to set on snapping of points and position the nodes using the node editor.
(BTW, in any case, the x, y, w and h values take the stroke of the
line
into account.)
I'll give that a shot and see. When I was doing the actual drawing, I experimented with a bunch of variations of the snap options, so I really don't know which combinations I tried. I do know that my experience was when I could get the boxes to touch, the snap wasn't absolute and I ended up with stacks of 64x64 not being the same height as a single 64x192 rectangle. That's when I started doing the offsets manually with the text boxes.
Mostly, I'm just trying to see if this behavior has been noticed by anyone else. If necessary, I can try and put together a reproduceable test case and enter a bug.
Thanks for your help,
ast
Hi people !
With my Inkscape ver. 0.42+0.43pre1 (Oct 26 2005) I can't fully control the command "text on trace". As you can see I can put it on the up side of the curve (inserting spaces before the string) but I can't do the same with the bottom side (see the attached picture)
It's the same with newer versions of Inkscape ?
Do you know an alternative way to do what I need ?
R.
Duplicate the elipse, flip it horizontally and attach the text to it. You might have to flip it vertically too, play around.
/d
On Tuesday 14 November 2006 08:13, RoSourceforge wrote:
Hi people !
With my Inkscape ver. 0.42+0.43pre1 (Oct 26 2005) I can't fully control the command "text on trace". As you can see I can put it on the up side of the curve (inserting spaces before the string) but I can't do the same with the bottom side (see the attached picture)
It's the same with newer versions of Inkscape ?
Do you know an alternative way to do what I need ?
R.
At 07.21 14/11/2006, you wrote:
Duplicate the elipse, flip it horizontally and attach the text to it. You might have to flip it vertically too, play around.
many thanks Donn ! I filled all objects except for the eclipse ! Thank you very much !
R.
On Tuesday 14 November 2006 08:13, RoSourceforge wrote:
Hi people !
With my Inkscape ver. 0.42+0.43pre1 (Oct 26 2005) I can't fully control the command "text on trace". As you can see I can put it on the up side of the curve (inserting spaces before the string) but I can't do the same with the bottom side (see the attached picture)
It's the same with newer versions of Inkscape ?
Do you know an alternative way to do what I need ?
R.
-- With soap, baptism is a good thing. -- Robert Green Ingersoll
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
Hi,
I checked through the keybindings settings and the wiki, but failed to find an info.
Have you tried editing /usr/share/inkscape/ui/keybindings.rc?
Yes, I had had a look at it before I posted my e-mail to the list. You can toggle windows et al that way only it seems.
I looked for a listing of Inkscape actions like "centering" or similar, but found none.
participants (9)
-
Alan Horkan -
Andrew S. Townley -
Bryce Harrington -
bulia byak -
Donn -
Jasper van de Gronde -
Kinsley Turner -
RoSourceforge -
Thorsten