Problems loading plain svg produced by inkscape

[Wolfiq]

Hi,

I got a report in debian's BTS at
http://bugs.debian.org/276858 against version 0.39 long
time ago, and I thought I had it forwarded, but this
doesn't seem to be the case and it is still
reproducible in current cvs. There are actually two
problems in the original report for which I'll submit
two tracker items. So here is the first: The user
created the attached file and saved it as "plain svg".
On the next load inkscape issues some warnings:

Aus-Knopf.svg:31: namespace error : Namespace prefix
rdf on RDF is not defined
       id="RDF11">
                 ^
Aus-Knopf.svg:34: namespace error : Namespace prefix
rdf for about on Work is not defined
         id="Work12">
                    ^
Aus-Knopf.svg:34: namespace error : Namespace prefix cc
on Work is not defined
         id="Work12">
                    ^
Aus-Knopf.svg:36: namespace error : Namespace prefix dc
on format is not defined
           id="format13">image/svg+xml</dc:format>
                        ^
Aus-Knopf.svg:39: namespace error : Namespace prefix
rdf for resource on type is not defined

rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

          ^
Aus-Knopf.svg:39: namespace error : Namespace prefix dc
on type is not defined

rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

          ^

I think this is rather odd, since the file was produced
by inkscape itself.

Thanks,

Wolfi

[Wolfram Quester (wolfi)]

Hi Andreas,

On Sun, Oct 17, 2004 at 01:41:02AM +0200, Andreas Neudecker wrote:
> Package: inkscape
> Version: 0.39-6
> Severity: normal
>
> Even with simple graphics exported PS or EPS files cannot be displayed
> or converted by gs, gv, gnome-gv. gv displays the following error message:
>
> 8<------------------------------------------------------------------------------
> Execution stack:
> %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 2 3 %oparray_pop --nostringval-- --nostringval--
> Dictionary stack:
> --dict:1053/1417(ro)(G)-- --dict:0/20(G)-- --dict:68/200(L)--
> Current allocation mode is local
> ESP Ghostscript 7.07.1: Unrecoverable error, exit code 1
> 8<------------------------------------------------------------------------------
>
> Consequently it is not possible to export usable postscript files from inkscape.
>
>
> Here the PS and EPS code (the svg is attached).
>
>

Thanks for your report! I can reproduce the error with the file you sent
in. However opening this file with inkscape version 0.39 gives the
following warnings on the console:

/tmp/Aus-Knopf.svg:31: namespace error : Namespace prefix rdf on RDF is
not defined
       id="RDF11">
                 ^
/tmp/Aus-Knopf.svg:34: namespace error : Namespace prefix rdf for about
on Work is not defined
         id="Work12">
                    ^
/tmp/Aus-Knopf.svg:34: namespace error : Namespace prefix cc on Work is
not defined
         id="Work12">
                    ^
/tmp/Aus-Knopf.svg:36: namespace error : Namespace prefix dc on format
is not defined
           id="format13">image/svg+xml</dc:format>
                        ^
/tmp/Aus-Knopf.svg:39: namespace error : Namespace prefix rdf for
resource on type is not defined
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
                                                                 ^
/tmp/Aus-Knopf.svg:39: namespace error : Namespace prefix dc on type is
not defined
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
                                                                 ^

This and the header of the file makes me believe that the file was
created with a rather old version of inkscape. Do you know by any chance
with which inkscape version it was created? I tested ver. 0.36 with the
same result.
Attached is a file which prints fine here. Could you please test it?

With best regards,

Wolfi

[zapyon (zapyon)]

Hi Wolfram,

> However opening this file with inkscape version 0.39 gives the
> following warnings on the console:

Didn't know this.

> This and the header of the file makes me believe that the file was
> created with a rather old version of inkscape. Do you know by any chance
> with which inkscape version it was created? I tested ver. 0.36 with the
> same result.

No. The file was produced in 0.39 seconds before I tried to create the PS
files. May be it has something to do with the fact that I tried saving as
"plain SVG"?

> Attached is a file which prints fine here. Could you please test it?

Sure.

Kind regards

Andreas

--
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

[zapyon (zapyon)]

Hi again, Wolfram.

> Attached is a file which prints fine here. Could you please test it?

I tried your working version of the file now.
Export as PS + EPS okay. Puzzling. But it gets better:
I saved this file as plain SVG, exited inkscape and restarted it with this
file again. Export as PS + EPS okay.

BUT: This is a different machine now. I will repeat this at home.

Also strange: This has happened to me before and frequently. I do not
remember having succeeded in exporting PS/EPS from inkscape. I just tried
with 0.39 because I hoped it would work now. And like now, I have usually
been trying with a simple new drawing. Strange.

Any idea what I should be looking for? (Like steps during the process of
creating such a drawing? Though they were usually really simple)

Kind regards

Andreas

--
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

[Wolfram Quester (wolfi)]

Hi Andreas,

On Mon, Oct 18, 2004 at 10:07:51PM +0200, Andreas Neudecker wrote:
> Hi again, Wolfram.
>
> > Attached is a file which prints fine here. Could you please test it?
>
> I tried your working version of the file now.
> Export as PS + EPS okay. Puzzling. But it gets better:
> I saved this file as plain SVG, exited inkscape and restarted it with this
> file again. Export as PS + EPS okay.
The same here. But after opening this plain SVG file I get the
aforementione warnings. This seems buggy to me.
>
> BUT: This is a different machine now. I will repeat this at home.
>
> Also strange: This has happened to me before and frequently. I do not
> remember having succeeded in exporting PS/EPS from inkscape. I just tried
> with 0.39 because I hoped it would work now. And like now, I have usually
> been trying with a simple new drawing. Strange.
>
> Any idea what I should be looking for? (Like steps during the process of
> creating such a drawing? Though they were usually really simple)
No, not really. It seems saving as inkscape-svg is the safest
possibility. I never used plain svg and had no problems, exept the ones
known upstream, as no gradients and transparancy. This because inkscape
produces only PS Level 2, but these features were introduced with level
3. There are plans to implement a new ps engine for Level 3 though. As
long there is the workaround of printing "as bitmap"
>
>
> Kind regards
>
>
> Andreas
>
Thanks for your help,

Wolfi

[mherrn (mherrn)]

Package: inkscape
Version: 0.41-4.99.sarge0
Followup-For: Bug #276858

I have the same problems exporting to EPS with SVG files made by
Borland Together. I imported the SVG file in inkscape, edited it a bit
and exported to EPS.

An example SVG file from Together is appended.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.25-1-386
Locale: LANG=POSIX, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages inkscape depends on:
ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgc1 1:6.4-1 conservative garbage collector for
ii libgcc1 1:3.4.3-13 GCC support library
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libglibmm-2.4-1 2.6.1-1 C++ wrapper for the GLib toolkit (
ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface
ii libgtkmm-2.4-1 2.4.10-1 C++ wrappers for GTK+ 2.4 (shared
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii libsigc++-2.0-0 2.0.10-1 type-safe Signal Framework for C++
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii libxft2 2.1.7-1 FreeType-based font drawing librar
ii libxml2 2.6.16-7 GNOME XML library
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxslt1.1 1.1.12-8 XSLT processing library - runtime
ii xlibs 4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4 compression library - runtime

-- no debconf information

[Wolfram Quester (wolfi)]

On Tue, Jun 07, 2005 at 11:31:48AM +0200, mherrn wrote:
> Package: inkscape
> Version: 0.41-4.99.sarge0
> Followup-For: Bug #276858
>
> I have the same problems exporting to EPS with SVG files made by
> Borland Together. I imported the SVG file in inkscape, edited it a bit
> and exported to EPS.
>
> An example SVG file from Together is appended.

Hi and thanks for your report.

Am I right that the problems you mention are the millions of
** (inkscape:6548): WARNING **: Unimplemented style property SP_PROP_CLIP_PATH: value: url(#clipPath65)
showing up on your terminal window and that the canvas/paper size does
not match the dimensions in Borland Together? Or are the relative
positions of the boxes also changed between the two apps? Fonts are
imported correctly by inkscape or not?
BTW, was the file created with the windows or Linux version of Borland
Together?

Concerning the eps problemas there are quite a lot known upstream and at
the moment I try to fix some of them, but eps export is far from good.

With best wishes,

Wolfi

[Marco Herrn (marco-herrn)]

Hi,

> Am I right that the problems you mention are the millions of
> ** (inkscape:6548): WARNING **: Unimplemented style property SP_PROP_CLIP_PATH: value: url(#clipPath65)
> showing up on your terminal window and that the canvas/paper size does
> not match the dimensions in Borland Together?

Well, that was not the problem I reported, but you are right :-) The only differences to the above is, that it refers to (inkscape:3030) and url(#clipPath85)

> Or are the relative
> positions of the boxes also changed between the two apps?

The relative positions look quite well. I don't see a difference there to the original.

> Fonts are
> imported correctly by inkscape or not?

The fonts look good, but are not the same, since some are too wide for the boxes.

> BTW, was the file created with the windows or Linux version of Borland
> Together?

It was created with the linux version. Actually it was made with the Community Edition (which isn't available anymore). I don't know whether this happens with other versions of Together.

> Concerning the eps problemas there are quite a lot known upstream and at
> the moment I try to fix some of them, but eps export is far from good.

That unfortunate, since inkscape was the only software I found, that at least pretended to convert from SVG to EPS. ;-)

Regards
Marco

[Wolfram Quester (wolfi)]

Hi,

On Thu, Jun 09, 2005 at 01:23:55PM +0200, Marco Herrn wrote:
> Hi,
>
> > Am I right that the problems you mention are the millions of
> > ** (inkscape:6548): WARNING **: Unimplemented style property SP_PROP_CLIP_PATH: value: url(#clipPath65)
> > showing up on your terminal window and that the canvas/paper size does
> > not match the dimensions in Borland Together?
>
> Well, that was not the problem I reported, but you are right :-) The
> only differences to the above is, that it refers to (inkscape:3030)
> and url(#clipPath85)
Sorry for missing the original subject of your mail. I didn't realise
the contaxt of your info and took it as a new bugreport.
>
> > Or are the relative
> > positions of the boxes also changed between the two apps?
>
> The relative positions look quite well. I don't see a difference there
> to the original.
>
> > Fonts are
> > imported correctly by inkscape or not?
>
> The fonts look good, but are not the same, since some are too wide for the boxes.
>
> > BTW, was the file created with the windows or Linux version of Borland
> > Together?
>
> It was created with the linux version. Actually it was made with the
> Community Edition (which isn't available anymore). I don't know
> whether this happens with other versions of Together.
Ok, this probably means that inkscape can't find the fonts installed for
Together. It might be a configuration problem, though. Is the path to
these fonts in your /etc/X11/XF86Config-4?
>
> > Concerning the eps problemas there are quite a lot known upstream and at
> > the moment I try to fix some of them, but eps export is far from good.
>
> That unfortunate, since inkscape was the only software I found, that
> at least pretended to convert from SVG to EPS. ;-)
Well, I just tested eps-export from the cvs-version of inkscape and gv
doesn't crash anymore. I attach the resulting eps-file which corresponds
exactly to the view I get in inkscape. Fonts are messed up, which is
probably because I don't have your fonts installed. But I guess some
lines connecting the boxes are missing as a consequence of the
"Unimplemented style property SP_PROP_CLIP_PATH".

This looks as if we could close the eps-part of this bug with the next
release and open a new one on the difficulties of opening svgs produced
by other applications. I'll forward this part including your example
file upstream if you don't mind.

With best regards,

Wolfi

[Marco Herrn (marco-herrn)]

Hi,

> > > BTW, was the file created with the windows or Linux version of Borland
> > > Together?
> >
> > It was created with the linux version. Actually it was made with the
> > Community Edition (which isn't available anymore). I don't know
> > whether this happens with other versions of Together.
> Ok, this probably means that inkscape can't find the fonts installed for
> Together. It might be a configuration problem, though. Is the path to
> these fonts in your /etc/X11/XF86Config-4?

No, they are not. I now added the fonts to the XF86Config-4, but it didn't change. But it seems that Together only set the font to sans-serif, so inkscape would have to guess which sans-serif font to use. (sodipodi uses a font that fits quite well, but also isn't exactly the one used by Together).
I now added the fonts to my config, and set it explicitly to Lucida Sans (which is also resembled in the svg), but inkscape still doesn't use it. Interestingly inkscape doesn't offer me all fonts that are available to xfontconfig, for example xfontconfig shows me Lucida Sans (which is the one used by Together), but inkscape doesn't.

> Well, I just tested eps-export from the cvs-version of inkscape and gv
> doesn't crash anymore. I attach the resulting eps-file which corresponds
> exactly to the view I get in inkscape.

Yes, that's right. gv reads it in without complaining. Also using it in a LaTeX file works quite well.

> Fonts are messed up, which is
> probably because I don't have your fonts installed.

Yes, but that is also the case when opening the SVG file, so it not specific to the EPS output.

> But I guess some
> lines connecting the boxes are missing as a consequence of the
> "Unimplemented style property SP_PROP_CLIP_PATH".

No, all connections are there. The only thing which is not absolutely correct are the two connections to the note. These are dotted lines (after opening the SVG in inkscape they are still dotted), but in the output are full lines.

> This looks as if we could close the eps-part of this bug with the next
> release and open a new one on the difficulties of opening svgs produced
> by other applications. I'll forward this part including your example
> file upstream if you don't mind.

Yes, that is absolutely ok to me.

Regards
Marco

[Wolfiq (wolfiq)]

Hi,

I got a report in debian's BTS at
http://bugs.debian.org/276858 against version 0.39 long
time ago, and I thought I had it forwarded, but this
doesn't seem to be the case and it is still
reproducible in current cvs. There are actually two
problems in the original report for which I'll submit
two tracker items. So here is the first: The user
created the attached file and saved it as "plain svg".
On the next load inkscape issues some warnings:

Aus-Knopf.svg:31: namespace error : Namespace prefix
rdf on RDF is not defined
       id="RDF11">
                 ^
Aus-Knopf.svg:34: namespace error : Namespace prefix
rdf for about on Work is not defined
         id="Work12">
                    ^
Aus-Knopf.svg:34: namespace error : Namespace prefix cc
on Work is not defined
         id="Work12">
                    ^
Aus-Knopf.svg:36: namespace error : Namespace prefix dc
on format is not defined
           id="format13">image/svg+xml</dc:format>
                        ^
Aus-Knopf.svg:39: namespace error : Namespace prefix
rdf for resource on type is not defined

rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

          ^
Aus-Knopf.svg:39: namespace error : Namespace prefix dc
on type is not defined

rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

          ^

I think this is rather odd, since the file was produced
by inkscape itself.

Thanks,

Wolfi

[Wolfram Quester (wolfi)]

Hi Andreas,

On Mon, Oct 18, 2004 at 10:07:51PM +0200, Andreas Neudecker wrote:
> Hi again, Wolfram.
>
> > Attached is a file which prints fine here. Could you please test it?
>
> I tried your working version of the file now.
> Export as PS + EPS okay. Puzzling. But it gets better:
> I saved this file as plain SVG, exited inkscape and restarted it with this
> file again. Export as PS + EPS okay.
>
> BUT: This is a different machine now. I will repeat this at home.
>
> Also strange: This has happened to me before and frequently. I do not
> remember having succeeded in exporting PS/EPS from inkscape. I just tried
> with 0.39 because I hoped it would work now. And like now, I have usually
> been trying with a simple new drawing. Strange.
>
> Any idea what I should be looking for? (Like steps during the process of
> creating such a drawing? Though they were usually really simple)
>
I'm sorry for nor taking care of this bug for this long time, but it
recently got my attention again. I'm in the process of splitting it up
and submitting it upstream. I analysed the ps-output and found the
problem in your file. The line
[0.0000000 0.0000000] 0.0000000 setdash
is not conforming to the ps-standard. It should read
[ ] 0.0000000 setdash
During creation of the file, did you change the settings of the line?
The svg is properly exported to ps and displayed in gv, if I remove the
"stroke-dasharray:0.0000000 0.0000000; " item from the <path d> Element
in your svg.

Thanks again and sorry for the delay,

Wolfi
>
> Kind regards
>
>
> Andreas
>
>
>
> --
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

[Wolfram Quester (wolfi)]

# Automatically generated email from bts, devscripts version 2.8.14
forwarded 276858 http://sourceforge.net/tracker/index.php?func=detail&aid=1226260&group_id=93438&atid=604306

[Wolfram Quester (wolfi)]

Hi Marco,

> > This looks as if we could close the eps-part of this bug with the next
> > release and open a new one on the difficulties of opening svgs produced
> > by other applications. I'll forward this part including your example
> > file upstream if you don't mind.
>
> Yes, that is absolutely ok to me.

I forwarded your bug report upstream at
http://sourceforge.net/tracker/index.php?func=detail&aid=1226340&group_id=93438&atid=604306

There are two other report, which were split off from this bug report at
http://sourceforge.net/tracker/index.php?func=detail&aid=1226282&group_id=93438&atid=604306
http://sourceforge.net/tracker/index.php?func=detail&aid=1226260&group_id=93438&atid=604306

I had a closer look to your and Andreas's eps-export problem and it
turned out that these are two different things. Yours is resolved
upstream, Andreas' not.

With best wishes,

Wolfi
>
> Regards
> Marco

[Buliabyak-users (buliabyak-users)]

Of course this file will always give warnings because it is
invalid. It does not mean the current Inkscape has a bug. It
only means the version which created this file had a bug.
This bug has been fixed long ago. If you open this file and
resave it as plain SVG in CVS version, the new file is OK.

[mherrn (mherrn)]

Package: inkscape
Version: 0.40+0.41pre3-1
Followup-For: Bug #276858

Hi, I still have problems exporting to EPS. I also tried the current
CVS version. The problem still exists there.

The error message when reading the file with gv is:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push 1 3
%oparray_pop 1 3 %oparray_pop --nostringval-- 1 3
%oparray_pop 1 3 %oparray_pop .runexec2 --nostringval--
--nostringval-- --nostringval-- 2 %stopped_push
--nostringval-- 2 3 %oparray_pop --nostringval--
--nostringval-- --nostringval--
Dictionary stack:
   --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:73/200(L)--
Current allocation mode is local
Current file position is 320359
GPL Ghostscript 8.01: Unrecoverable error, exit code 1

The source SVG and the exported EPS are attached.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.25-1-386
Locale: LANG=POSIX, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages inkscape depends on:
ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit
ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgc1 1:6.4-1 conservative garbage collector for
ii libgcc1 1:3.4.3-13 GCC support library
ii libgconf2-4 2.8.1-6 GNOME configuration database syste
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libglibmm-2.4-1 2.6.1-1 C++ wrapper for the GLib toolkit (
ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr
ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface
ii libgtkmm-2.4-1 2.4.10-1 C++ wrappers for GTK+ 2.4 (shared
ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii libsigc++-2.0-0 2.0.10-1 type-safe Signal Framework for C++
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii libxft2 2.1.7-1 FreeType-based font drawing librar
ii libxml2 2.6.16-7 GNOME XML library
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxslt1.1 1.1.12-8 XSLT processing library - runtime
ii xlibs 4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu
ii zlib1g 1:...

[mherrn (mherrn)]

Package: inkscape
Version: 0.40+0.41pre3-1
Followup-For: Bug #276858

According to Wolframs hint to Andreas about the stroke-dasharray, I
just modified the SVG file manually and (without knowing what I am
really doing) removed all the stroke-dasharray attributes. Now the
export works. There no dashed lines anymore, instead they are full
strokes, but this seems to be the problem, that those dashes are wrong
converted to PS.

Regards
Marco

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.25-1-386
Locale: LANG=POSIX, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages inkscape depends on:
ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit
ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgc1 1:6.4-1 conservative garbage collector for
ii libgcc1 1:3.4.3-13 GCC support library
ii libgconf2-4 2.8.1-6 GNOME configuration database syste
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libglibmm-2.4-1 2.6.1-1 C++ wrapper for the GLib toolkit (
ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr
ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface
ii libgtkmm-2.4-1 2.4.10-1 C++ wrappers for GTK+ 2.4 (shared
ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii libsigc++-2.0-0 2.0.10-1 type-safe Signal Framework for C++
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii libxft2 2.1.7-1 FreeType-based font drawing librar
ii libxml2 2.6.16-7 GNOME XML library
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxslt1.1 1.1.12-8 XSLT processing library - runtime
ii xlibs 4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information

[Bts-link-upstream (bts-link-upstream)]

#
# bts-link upstream status pull for source package inkscape
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #232216
# * http://sourceforge.net/tracker/?func=detailatid=604309&aid=909735&group_id=93438
# * remote status changed: (?) -> Open
usertags 232216 + status-Open

# remote status report for #244854
# * http://sourceforge.net/tracker/?func=detailatid=604309&aid=938707&group_id=93438
# * remote status changed: (?) -> Closed
usertags 244854 + status-Closed

# remote status report for #276858
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1226260&group_id=93438
# * remote status changed: (?) -> Closed
# * remote resolution changed: (?) -> Out-of-Date
# * closed upstream
tags 276858 + fixed-upstream
usertags 276858 + status-Closed resolution-Out-of-Date

# remote status report for #283727
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1078273&group_id=93438
# * remote status changed: (?) -> Closed
# * remote resolution changed: (?) -> Fixed
# * closed upstream
tags 283727 + fixed-upstream
usertags 283727 + status-Closed resolution-Fixed

# remote status report for #286588
# * http://sourceforge.net/tracker/?func=detailatid=604309&aid=1090323&group_id=93438
# * remote status changed: (?) -> Open
usertags 286588 + status-Open

# remote status report for #292676
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1112537&group_id=93438
# * remote status changed: (?) -> Open
usertags 292676 + status-Open

# remote status report for #293290
# * http://sourceforge.net/tracker/?func=detailatid=604309&aid=1115355&group_id=93438
# * remote status changed: (?) -> Closed
# * closed upstream
tags 293290 + fixed-upstream
usertags 293290 + status-Closed

# remote status report for #326051
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1303192&group_id=93438
# * remote status changed: (?) -> Open
usertags 326051 + status-Open

# remote status report for #329075
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1170322&group_id=93438
# * remote status changed: (?) -> Open
usertags 329075 + status-Open

# remote status report for #347814
# * http://sourceforge.net/tracker/?func=detailatid=604306&aid=1089414&group_id=93438
# * remote status changed: (?) -> Open
usertags 347814 + status-Open

thanks

[Alex Valavanis (valavanisalex)]

forwarded 276858 https://bugs.launchpad.net/debian/+source/inkscape/+bug/166645
thanks

[Alex Valavanis (valavanisalex)]

Version: 0.42-1

Fixed upstream long ago... see
https://bugs.launchpad.net/debian/+source/inkscape/+bug/166645