From Joop Sun Aug 1 13:44:52 2010
From: Joop
To: inkscape-user@lists.inkscape.org
Subject: [Inkscape-user] Portrait composed with small tiled portaits
Date: Sun, 01 Aug 2010 15:32:39 +0200
Message-ID: <4C557777.4090509@...2215...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6834362941765892852=="
--===============6834362941765892852==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
--===============6834362941765892852==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.htm"
MIME-Version: 1.0
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl
IiBjb250ZW50PSJ0ZXh0L2h0bWw7CiAgICAgIGNoYXJzZXQ9SVNPLTg4NTktMSI+CiAgPC9oZWFk
PgogIDxib2R5IGJnY29sb3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGZvbnQgZmFj
ZT0iSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiI+V2l0aCBhIGZyaWVuZCBJIHNhdyBhIGJp
ZwogICAgICBwb3J0cmFpdCBpbWFnZSB0aGF0IGhhcyBhIGdvb2QgbGlrZW5pbmcgb2YgdGhlIHBl
cnNvbiB3aGVuIHlvdQogICAgICBsb29rIGF0IGl0IGZyb20gYSBkaXN0YW5jZS4gQnV0IHdoZW4g
eW91IGdldCBuZWFyZXIgeW91IHNlZSB0aGF0CiAgICAgIHRoZSBwb3J0cmFpdCBpcyBjb21wb3Nl
ZCB3aXRoIGEgaHVnZSBudW1iZXIgb2Ygc21hbGwgcG9ydHJhaXRzIG9mCiAgICAgIGRpZmZlcmVu
dCBwZXJzb25zLCBhbGwgdGlsZWQgc2lkZSBieSBzaWRlOiBzbyB0aGUgcG9ydHJhaXQgaGFzCiAg
ICAgICJiaWcgcGl4ZWxzIHRoYXQgYXJlIGluIGl0c2VsZiBzbWFsbCBpbWFnZXMiLjxicj4KICAg
ICAgPGJyPgogICAgICBJIHdvdWxkIGxpa2UgdG8gbWFrZSBzdWNoIGEgcG9ydHJhaXQuIEZpcnN0
IHVzaW5nIG9ubHkgb25lCiAgICAgIHBvcnRyYWl0IGFzIHNtYWxsIGltYWdlIHRvIGNvbXBvc2Ug
YSBiaWdnZXIgdGlsZWQgaW1hZ2Ugb2YgdGhlCiAgICAgIHNhbWUgcG9ydHJhaXQuIExhdGVyIGFs
c28gdXNpbmcgZGlmZmVyZW50IHBvcnRyYWl0cy48YnI+CiAgICAgIDxicj4KICAgICAgQ2FuIHNv
bWVvbmUgdGVsbCBtZSB3aGF0IHByb2dyYW0gKElua3NjYXBlLCBHaW1wLCBTY3JpYnVzKSBJIGNh
bgogICAgICB1c2UgZm9yIHRoaXMgYW5kIElmIHRoZXJlIGlzIGEgbWFudWFsIGZvciB0aGUgcHJv
Y2VkdXJlLiBJIGNvdWxkCiAgICAgIG5vdCBmaW5kIGl0IG9uIHRoZSBpbnRlcm5ldCwgYnV0IGRp
ZG4ndCBrbm93IHdlbGwgaG93IHRvIGRlc2NyaWJlCiAgICAgIHRoaXMgcHJvY2VkdXJlIGluIGEg
ZmV3IHdvcmRzIDxzcGFuIGNsYXNzPSJtb3otc21pbGV5LXMxIj48c3Bhbj4KICAgICAgICAgIDot
KSA8L3NwYW4+PC9zcGFuPi48YnI+CiAgICAgIDxicj4KICAgICAgSm9vcDxicj4KICAgIDwvZm9u
dD4gPGJyPgogIDwvYm9keT4KPC9odG1sPgoK
--===============6834362941765892852==--
From John Culleton Sun Aug 1 17:54:03 2010
From: John Culleton
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] Portrait composed with small tiled portaits
Date: Sun, 01 Aug 2010 13:47:15 -0400
Message-ID: <201008011347.15159.john@...1668...>
In-Reply-To: <4C557777.4090509@...2215...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4671149145793613912=="
--===============4671149145793613912==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
On Sunday 01 August 2010 09:32:39 Joop wrote:
>
>
>
>
>
>
> With a friend I saw a big
> portrait image that has a good likening of the person when you
> look at it from a distance. But when you get nearer you see that
> the portrait is composed with a huge number of small portraits of
> different persons, all tiled side by side: so the portrait has
> "big pixels that are in itself small images".
>
> I would like to make such a portrait. First using only one
> portrait as small image to compose a bigger tiled image of the
> same portrait. Later also using different portraits.
>
> Can someone tell me what program (Inkscape, Gimp, Scribus) I can
> use for this and If there is a manual for the procedure. I could
> not find it on the internet, but didn't know well how to describe
> this procedure in a few words
>
> :-) .
>
>
> Joop
>
>
>
PLease don't use html. Tiling can be done in any of the above programs.
But I would probably try Gimp first.
--
John Culleton
Wexford Press
"Create Book Covers with Scribus"
Printable E-book 38 pages $5.95
http://www.booklocker.com/books/4055.html
--===============4671149145793613912==--
From Terry Brown Sun Aug 1 18:00:14 2010
From: Terry Brown
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] Portrait composed with small tiled portaits
Date: Sun, 01 Aug 2010 12:44:57 -0500
Message-ID: <20100801124457.7eae28bb@...2525...>
In-Reply-To: <4C557777.4090509@...2215...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2901345089451729891=="
--===============2901345089451729891==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On Sun, 01 Aug 2010 15:32:39 +0200
Joop wrote:
> With a friend I saw a big
> portrait image that has a good likening of the person when you
> look at it from a distance. But when you get nearer you see that
> the portrait is composed with a huge number of small portraits of
> different persons, all tiled side by side: so the portrait has
> "big pixels that are in itself small images".
I though Gimp included a plugin to do that. I wrote some code to do it mysel=
f once, using imagemagick, probably, I don't recall. But I'm sure I've seen =
a version with a GUI in lunix, I'm guessing Gimp, possibly with a perl or pyt=
hon dependency...
Bah, just looked through all of Gimp's menus and Synaptic's packages (Ubuntu =
10.4, filtered by "tile"), and can't find it. But it's out there, I've seen=
it :-}
Cheers -Terry
--===============2901345089451729891==--
From Joop Sun Aug 1 19:56:56 2010
From: Joop
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] Portrait composed with small tiled portaits
Date: Sun, 01 Aug 2010 21:56:59 +0200
Message-ID: <4C55D18B.8080904@...2215...>
In-Reply-To: <20100801124457.7eae28bb@...2525...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7603774517356491134=="
--===============7603774517356491134==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Op 1-8-2010 19:44, Terry Brown schreef:
> On Sun, 01 Aug 2010 15:32:39 +0200
> Joop wrote:
>
>> With a friend I saw a big
>> portrait image that has a good likening of the person when you
>> look at it from a distance. But when you get nearer you see that
>> the portrait is composed with a huge number of small portraits of
>> different persons, all tiled side by side: so the portrait has
>> "big pixels that are in itself small images".
>
> I though Gimp included a plugin to do that. I wrote some code to do it mys=
elf once, using imagemagick, probably, I don't recall. But I'm sure I've see=
n a version with a GUI in lunix, I'm guessing Gimp, possibly with a perl or p=
ython dependency...
>
> Bah, just looked through all of Gimp's menus and Synaptic's packages (Ubunt=
u 10.4, filtered by "tile"), and can't find it. But it's out there, I've se=
en it :-}
>
> Cheers -Terry
>
> ---------------------------------------------------------------------------=
---
Terry and Christopher,
Thanks for replying.
I too went through several plugin lists for Gimp but could not find=20
such. Saw a lot of other very nice plugins but that's for later :-).
But if you both are sure that it's out there, I'll continue to look/ask=20
around in the Gimp-files/community.
Joop
--===============7603774517356491134==--
From John Cliff Sun Aug 1 20:11:59 2010
From: John Cliff
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] Portrait composed with small tiled portaits
Date: Sun, 01 Aug 2010 21:12:17 +0100
Message-ID: <56392E75-080F-4BCF-A923-C87177B25098@...155...>
In-Reply-To: <4C55D18B.8080904@...2215...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3290505180586788654=="
--===============3290505180586788654==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
http://mosait.tangui.eu.org/
Or=20
www.linux.com/archive/feed/125624=20
Or just google
open source photo mosaic
Sent from my iPhone
On 1 Aug 2010, at 20:56, Joop wrote:
> Op 1-8-2010 19:44, Terry Brown schreef:
>> On Sun, 01 Aug 2010 15:32:39 +0200
>> Joop wrote:
>>=20
>>> With a friend I saw a big
>>> portrait image that has a good likening of the person when you
>>> look at it from a distance. But when you get nearer you see that
>>> the portrait is composed with a huge number of small portraits of
>>> different persons, all tiled side by side: so the portrait has
>>> "big pixels that are in itself small images".
>>=20
>> I though Gimp included a plugin to do that. I wrote some code to do it my=
self once, using imagemagick, probably, I don't recall. But I'm sure I've se=
en a version with a GUI in lunix, I'm guessing Gimp, possibly with a perl or =
python dependency...
>>=20
>> Bah, just looked through all of Gimp's menus and Synaptic's packages (Ubun=
tu 10.4, filtered by "tile"), and can't find it. But it's out there, I've s=
een it :-}
>>=20
>> Cheers -Terry
>>=20
>> --------------------------------------------------------------------------=
----
>=20
> Terry and Christopher,
>=20
> Thanks for replying.
> I too went through several plugin lists for Gimp but could not find=20
> such. Saw a lot of other very nice plugins but that's for later :-).
>=20
> But if you both are sure that it's out there, I'll continue to look/ask=20
> around in the Gimp-files/community.
>=20
> Joop
>=20
> ---------------------------------------------------------------------------=
---
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Inkscape-user mailing list
> Inkscape-user(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-user
--===============3290505180586788654==--
From Joop Sun Aug 1 22:25:01 2010
From: Joop
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] Portrait composed with small tiled portaits
Date: Mon, 02 Aug 2010 00:24:45 +0200
Message-ID: <4C55F42D.4030602@...2215...>
In-Reply-To: <56392E75-080F-4BCF-A923-C87177B25098@...155...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5940669803855693156=="
--===============5940669803855693156==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Op 1-8-2010 22:12, John Cliff schreef:
> http://mosait.tangui.eu.org/
>
> Or
>
> www.linux.com/archive/feed/125624
>
> Or just google
> open source photo mosaic
>
> Sent from my iPhone
>
John,
Thank you. This looks promising !
Joop
--===============5940669803855693156==--
From Joop Mon Aug 2 00:23:55 2010
From: Joop
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Portrait composed with small tiled portaits - SOLVED
Date: Mon, 02 Aug 2010 02:23:59 +0200
Message-ID: <4C56101F.8080905@...2215...>
In-Reply-To: <56392E75-080F-4BCF-A923-C87177B25098@...155...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8979971945833327015=="
--===============8979971945833327015==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Op 1-8-2010 22:12, John Cliff schreef:
> http://mosait.tangui.eu.org/
>
> Or
>
> www.linux.com/archive/feed/125624
>
> Or just google
> open source photo mosaic
>
John,
It is a pity that the Gimp plugin in no longer available.
But it looks like the program AndreaMosaic fits my needs.
Joop
--===============8979971945833327015==--
From ?????????? ?.?. Mon Aug 9 08:20:46 2010
From: =?utf-8?b?0J3Rg9GA0LzQuNC90YHQutC40Lkg0JUu0JAu?=
To: inkscape-user@lists.inkscape.org
Subject: [Inkscape-user] compiling problem for 0.47
Date: Mon, 09 Aug 2010 18:58:22 +1100
Message-ID:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3083844199448498283=="
--===============3083844199448498283==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
eraser-context.cpp: In function =E2=80=98void set_to_accumulated(SPEraserCont=
ext*)=E2=80=99:
eraser-context.cpp:752:55: error: =E2=80=98r=E2=80=99 was not declared in thi=
s scope
make[2]: *** [eraser-context.o] =D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B0 1
OS SuSE-11.3
--===============3083844199448498283==--
From ~suv Mon Aug 9 08:42:20 2010
From: ~suv
To: inkscape-user@lists.inkscape.org
Subject: Re: [Inkscape-user] compiling problem for 0.47
Date: Mon, 09 Aug 2010 10:42:08 +0200
Message-ID: <4C5FBF60.7060708@...16...>
In-Reply-To:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7346415142760563337=="
--===============7346415142760563337==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On 9/8/10 09:58, =D0=9D=D1=83=D1=80=D0=BC=D0=B8=D0=BD=D1=81=D0=BA=D0=B8=D0=B9=
=D0=95.=D0=90. wrote:
> eraser-context.cpp: In function =E2=80=98void set_to_accumulated(SPEraserCo=
ntext*)=E2=80=99:
> eraser-context.cpp:752:55: error: =E2=80=98r=E2=80=99 was not declared in t=
his scope
> make[2]: *** [eraser-context.o] =D0=9E=D1=88=D0=B8=D0=B1=D0=BA=D0=B0 1
see Bug #522327 =E2=80=9CInkscape 0.47 fails to build with GCC 4.5=E2=80=9D:
~suv
--===============7346415142760563337==--
From Alexander Roalter Tue Aug 17 14:22:17 2010
From: Alexander Roalter
To: inkscape-user@lists.inkscape.org
Subject:
[Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 16:07:50 +0200
Message-ID: <4C6A97B6.1080007@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0011505901364394036=="
--===============0011505901364394036==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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
--===============0011505901364394036==--
From Terry Brown Tue Aug 17 14:54:26 2010
From: Terry Brown
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 09:53:27 -0500
Message-ID: <20100817095327.55cf3590@...2525...>
In-Reply-To: <4C6A97B6.1080007@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9072804433694795928=="
--===============9072804433694795928==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
On Tue, 17 Aug 2010 16:07:50 +0200
Alexander Roalter 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
--===============9072804433694795928==--
From Alexander Roalter Tue Aug 17 15:42:36 2010
From: Alexander Roalter
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 17:42:12 +0200
Message-ID: <4C6AADD4.3080709@...2299...>
In-Reply-To: <20100817095327.55cf3590@...2525...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7366327145815440574=="
--===============7366327145815440574==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
On 17.08.2010 16:53, Terry Brown wrote:
> On Tue, 17 Aug 2010 16:07:50 +0200
> Alexander Roalter 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...
--
cheers,
Alex
--===============7366327145815440574==--
From Jasper van de Gronde Tue Aug 17 19:24:14 2010
From: Jasper van de Gronde
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 21:24:01 +0200
Message-ID: <4C6AE1D1.4080106@...226...>
In-Reply-To: <4C6A97B6.1080007@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3387333372276878914=="
--===============3387333372276878914==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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).
--===============3387333372276878914==--
From Alexander Roalter Tue Aug 17 20:34:36 2010
From: Alexander Roalter
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 21:55:29 +0200
Message-ID: <4C6AE931.8090605@...2299...>
In-Reply-To: <4C6AE1D1.4080106@...226...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2339219866002187994=="
--===============2339219866002187994==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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.
--
Cheers,
Alex
--===============2339219866002187994==--
From ricardo lafuente Tue Aug 17 23:07:22 2010
From: ricardo lafuente
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Tue, 17 Aug 2010 23:46:16 +0100
Message-ID: <4C6B1138.1040002@...2545...>
In-Reply-To: <4C6AE931.8090605@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4106118644050473178=="
--===============4106118644050473178==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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...
--===============4106118644050473178==--
From Jasper van de Gronde Wed Aug 18 08:41:06 2010
From: Jasper van de Gronde
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Wed, 18 Aug 2010 10:40:53 +0200
Message-ID: <4C6B9C95.4050801@...226...>
In-Reply-To: <4C6AE931.8090605@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1167475844921701822=="
--===============1167475844921701822==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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.
--===============1167475844921701822==--
From Alexander Roalter Wed Aug 18 09:25:27 2010
From: Alexander Roalter
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Wed, 18 Aug 2010 11:25:06 +0200
Message-ID: <4C6BA6F2.60709@...2299...>
In-Reply-To: <4C6B9C95.4050801@...226...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7436838593401857570=="
--===============7436838593401857570==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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.
--
cheers,
Alex
--===============7436838593401857570==--
From ~suv Wed Aug 18 10:53:52 2010
From: ~suv
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Wed, 18 Aug 2010 12:53:41 +0200
Message-ID: <4C6BBBB5.4010007@...16...>
In-Reply-To: <4C6BA6F2.60709@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4743024123552553930=="
--===============4743024123552553930==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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”
~suv
--===============4743024123552553930==--
From ~suv Wed Aug 18 11:29:47 2010
From: ~suv
To: inkscape-user@lists.inkscape.org
Subject:
Re: [Inkscape-user] Some usage questions and observations, mostly about paths
Date: Wed, 18 Aug 2010 13:29:33 +0200
Message-ID: <4C6BC41D.1000706@...16...>
In-Reply-To: <4C6BA6F2.60709@...2299...>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7605318278868210889=="
--===============7605318278868210889==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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 (