Some usage questions and observations, mostly about paths
I'm currently drawing a lot of maps, especially with municipality boundaries etc, this means a lot of closed paths, which should fit together like a puzzle. The snap function is a great help to this, but from another source I got some parts where the path is not closed, but the start and endpoint is there twice, without being connected.
Now I can select both start and endpoint, and click on the
-o o- v --o--
button (join selected end nodes) in the toolbar. Is there a shortcut for this? There isn't even a menu entry...
The same is valid: I have selected a subpath between two nodes, is there a way to add nodes in between other than the (+)-button in the toolbar? (I know of the double click, but if I want fast a lot of new nodes, this becomes rather tiresome.
Another thing with nodes: if I select only a few nodes from a path, and press the arrows, only these nodes move. The transformation tool though operates only on the entire path, so I cannot move a subset of nodes in a path by a fixed amount of pixels (e.g. make a zig zag line by selecting only the even nodes and moving them up a fixed amount).
I have only one object, let's say a rectangular shape on the canvas, from 100,100 to 300,200. If I now select 'adjust canvas size to object' from the document settings, the object in the xml still has 100,100, 300,200 as coordinates, but a transform(-100,-100) applied to it all. How can I apply the transformation to all objects, so that the object's coordinates (in the xml) would be 0,0 - 200,100?
And last, how does one make a distinction (and possibly convert) a path with absolute coordinates (uppercase M at the beginning of the path) to a path with relative coordinates (lowercase m)? I think this should be as easy as changing the path's direction
On Tue, 17 Aug 2010 16:07:50 +0200 Alexander Roalter <alexander@...2299...> wrote:
I'm currently drawing a lot of maps, especially with municipality boundaries etc, this means a lot of closed paths, which should fit together like a puzzle. The snap function is a great help to this, but from another source I got some parts where the path is not closed, but the start and endpoint is there twice, without being connected.
Now I can select both start and endpoint, and click on the
-o o- v --o--
button (join selected end nodes) in the toolbar. Is there a shortcut for this? There isn't even a menu entry...
Shift-J ? Help -> Keys and Mouse Reference
http://inkscape.org/doc/keys047.html#id2249692
The same is valid: I have selected a subpath between two nodes, is there a way to add nodes in between other than the (+)-button in the toolbar? (I know of the double click, but if I want fast a lot of new nodes, this becomes rather tiresome.
Insert-key from the same source.
Don't know about the other things.
Cheers -Terry
On 17.08.2010 16:53, Terry Brown wrote:
On Tue, 17 Aug 2010 16:07:50 +0200 Alexander Roalter <alexander@...2299...> wrote:
I'm currently drawing a lot of maps, especially with municipality boundaries etc, this means a lot of closed paths, which should fit together like a puzzle. The snap function is a great help to this, but from another source I got some parts where the path is not closed, but the start and endpoint is there twice, without being connected.
Now I can select both start and endpoint, and click on the
-o o- v --o--
button (join selected end nodes) in the toolbar. Is there a shortcut for this? There isn't even a menu entry...
Shift-J ? Help -> Keys and Mouse Reference
http://inkscape.org/doc/keys047.html#id2249692
The same is valid: I have selected a subpath between two nodes, is there a way to add nodes in between other than the (+)-button in the toolbar? (I know of the double click, but if I want fast a lot of new nodes, this becomes rather tiresome.
Insert-key from the same source.
Thank you for that... I remember reading the key manual, but this must have escaped me...
Alexander Roalter wrote:
... And last, how does one make a distinction (and possibly convert) a path with absolute coordinates (uppercase M at the beginning of the path) to a path with relative coordinates (lowercase m)? I think this should be as easy as changing the path's direction
Can you explain why you would need to? Currently it is treated simply as a different representation of the same path and Inkscape chooses the representation dynamically to optimize the size of the path data (which can drastically reduce file size).
On 08/17/2010 09:24 PM, Jasper van de Gronde wrote:
Alexander Roalter wrote:
... And last, how does one make a distinction (and possibly convert) a path with absolute coordinates (uppercase M at the beginning of the path) to a path with relative coordinates (lowercase m)? I think this should be as easy as changing the path's direction
Can you explain why you would need to? Currently it is treated simply as a different representation of the same path and Inkscape chooses the representation dynamically to optimize the size of the path data (which can drastically reduce file size).
It's more a matter of cleaning up the SVG. if I look through it, I see lots of things not needed in there, for unused defs to opacity, stroke-linecap, linejoin etc. declarations that only set the default value but clog up the file. In addition to be able to dynamically switching between relative/absolute coordinates, there should be a possibility to clean up the svg in a way, say loose unneeded declarations, apply transformations where possible, and even lower the precision on some cases/round to some extent.
On 08/17/2010 08:55 PM, Alexander Roalter wrote:
there should be a possibility to clean up the svg in a way, say loose unneeded declarations, apply transformations where possible, and even lower the precision on some cases/round to some extent.
+1 on this, is there any quick way to do these operations? I've thought repeatedly about doing a Python extension to accomplish this...
Alexander Roalter wrote:
On 08/17/2010 09:24 PM, Jasper van de Gronde wrote:
Alexander Roalter wrote:
... And last, how does one make a distinction (and possibly convert) a path with absolute coordinates (uppercase M at the beginning of the path) to a path with relative coordinates (lowercase m)? I think this should be as easy as changing the path's direction
Can you explain why you would need to? Currently it is treated simply as a different representation of the same path and Inkscape chooses the representation dynamically to optimize the size of the path data (which can drastically reduce file size).
It's more a matter of cleaning up the SVG. if I look through it, I see lots of things not needed in there, for unused defs to opacity,
I'm assuming you are aware of "vacuum defs"? If it fails to work, please file a bug report.
stroke-linecap, linejoin etc. declarations that only set the default value but clog up the file.
Yes, in general Inkscape needs to take those things into account more, if you have some specific examples we'd love to have a bug report for those. But realize that sometimes there is a fine line, in some cases "optimizing" our SVG may in fact be counterproductive in that it yields modest gains in file size and such but does obscure the SVG.
In addition to be able to dynamically switching between relative/absolute coordinates, there should be a possibility to clean up the svg in a way, say loose unneeded declarations, apply transformations where possible, and even lower the precision on some cases/round to some extent.
As I explained paths are currently already optimized by Inkscape (including but not limited to switching between relative/absolute), you're not going to be able to make the path data any smaller than it is right now (except by removing spaces and such, which was deliberately avoided). Is there any other reason for wanting to switch between relative and absolute coordinates?
As for the other things, a lot of that is already possible (Inkscape has two modes for applying transformations and you can set the precision at which it works). Any specific requests for enhancing the functionality are most welcome though.
I'd like to point to our bug tracker (which is also used for feature requests), if you file your request there it won't be easily forgotten: http://bugs.launchpad.net/inkscape/ We also have a section with blue prints on Launchpad that can be used for more general proposals.
On 18.08.2010 10:40, Jasper van de Gronde wrote:
I'm assuming you are aware of "vacuum defs"? If it fails to work, please file a bug report.
I'm aware of that function, and the defs were only one point in this list. I usually do a clean up in the xml editor.
stroke-linecap, linejoin etc. declarations that only set the default value but clog up the file.
Yes, in general Inkscape needs to take those things into account more, if you have some specific examples we'd love to have a bug report for those. But realize that sometimes there is a fine line, in some cases "optimizing" our SVG may in fact be counterproductive in that it yields modest gains in file size and such but does obscure the SVG.
What mostly bothers me is this behavior: I draw an object, and once I switch the opacity to check with the things that are below it (to do some tracing), and later go back to 100% opacity, inkscape keeps the opacity:1, without needing it. Same is valid for other options. If coordinates are rewritten dynamically between absolute/relative, I assume the other settings could also be reviewed when changes occur, if they are needed or not.
In addition to be able to dynamically switching between relative/absolute coordinates, there should be a possibility to clean up the svg in a way, say loose unneeded declarations, apply transformations where possible, and even lower the precision on some cases/round to some extent.
As I explained paths are currently already optimized by Inkscape (including but not limited to switching between relative/absolute), you're not going to be able to make the path data any smaller than it is right now (except by removing spaces and such, which was deliberately avoided). Is there any other reason for wanting to switch between relative and absolute coordinates?
I did not know yet that inkscape dynamically decides which way is shorter (in memory); if that's the case, then I don't need to switch all by myself.
As for the other things, a lot of that is already possible (Inkscape has two modes for applying transformations and you can set the precision at which it works). Any specific requests for enhancing the functionality are most welcome though.
I currently have the setting to 'optimize transformations'. After some testing, I found that what I'd need has to do with a grouped object (this also applies to the 'resize page size to object', which also produces a transformation:
If I move an object around, the coordinates are adjusted in the XML as expected. If the object is a group, the group gets a 'transform' tag which is only changed subsequently.
The only way to apply the transformation is to ungroup-regroup, which doesn't work on the entire page (after the 'resize page size to object'). Apparently, there's currently no way for doing this.
On 18/8/10 11:25, Alexander Roalter wrote:
On 18.08.2010 10:40, Jasper van de Gronde wrote:
I'm assuming you are aware of "vacuum defs"? If it fails to work, please file a bug report.
I'm aware of that function, and the defs were only one point in this list. I usually do a clean up in the xml editor.
stroke-linecap, linejoin etc. declarations that only set the default value but clog up the file.
Yes, in general Inkscape needs to take those things into account more, if you have some specific examples we'd love to have a bug report for those. But realize that sometimes there is a fine line, in some cases "optimizing" our SVG may in fact be counterproductive in that it yields modest gains in file size and such but does obscure the SVG.
What mostly bothers me is this behavior: I draw an object, and once I switch the opacity to check with the things that are below it (to do some tracing), and later go back to 100% opacity, inkscape keeps the opacity:1, without needing it. Same is valid for other options. If coordinates are rewritten dynamically between absolute/relative, I assume the other settings could also be reviewed when changes occur, if they are needed or not.
Bug #171983 “Reduce SVG file size by removing unnecessary attributes” https://bugs.launchpad.net/inkscape/+bug/171983
~suv
On 18/8/10 11:25, Alexander Roalter wrote:
On 18.08.2010 10:40, Jasper van de Gronde wrote:
As for the other things, a lot of that is already possible (Inkscape has two modes for applying transformations and you can set the precision at which it works). Any specific requests for enhancing the functionality are most welcome though.
I currently have the setting to 'optimize transformations'. After some testing, I found that what I'd need has to do with a grouped object (this also applies to the 'resize page size to object', which also produces a transformation:
If I move an object around, the coordinates are adjusted in the XML as expected. If the object is a group, the group gets a 'transform' tag which is only changed subsequently.
Not only groups always use 'preserved' transformation: - Inkscape shapes like ellipses, stars, polygons and spirals store even simple translation in the 'transform' attribute. - Inkscape's rectangles use preserved transforms for scaling or rotating. - Paths with an applied filter effect use preserved transforms for scaling or rotating. - AFAIU clones (<use>) have to use preserved transforms.
related: Bug #233935 “Moves of circle stored in transform Attribute” https://bugs.launchpad.net/inkscape/+bug/233935
The only way to apply the transformation is to ungroup-regroup, which doesn't work on the entire page (after the 'resize page size to object'). Apparently, there's currently no way for doing this.
You can delete the transform attribute of the layer(s) in the XML Editor. This will render the objects at their untransformed location. To realign the objects with the current page, select all objects in the layer and use the 'Align and Distribute' dialog to center the selection as group relative to the page (make sure to deselect all first after closing the XML Editor dialog and to activate the relevant layer again, before selecting all objects)
[ The 'transform' attribute that is added to the top-level layers/groups after resizing the page (or changing its size|orientation) often results in erratic behavior e.g. of tiled clones, connectors and some extensions (most of the errors appear to be caused by incorrect or missing handling of parent transforms of certain object types inside transformed groups). ]
~suv
participants (5)
-
Alexander Roalter -
Jasper van de Gronde -
ricardo lafuente -
Terry Brown -
~suv