Forum: Inkscape 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



--
cheers,
Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

On Tue, 17 Aug 2010 16:07:50 +0200
Alexander Roalter <alexander@roalter.it> wrote:

> --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

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

On 17.08.2010 16:53, Terry Brown wrote:
>>
> 
>> 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...


--
cheers,
Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

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).

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

On 08/17/2010 09:24 PM, Jasper van de Gronde wrote:
> 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.


--
Cheers,
Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

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...


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

Alexander Roalter wrote:
>> 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.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

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.

> 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.


--
cheers,
Alex

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

On 18/8/10 11:25, Alexander Roalter wrote:
>> Yes, in general Inkscape needs to take those things into account more, 
> 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

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

On 18/8/10 11:25, Alexander Roalter wrote:
> 
> 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

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev