As 2008 comes to a close I wanted to wish a happy holiday season to all
and to wish everyone a very happy, healthy, safe, and prosperous new
year! A big "THANK YOU!" goes out to to all contributors... whether
developers, translators, testers, users, or even just advocates or
constructive critics, Inkscape would not be where it is today without
everything that you all have given. Thanks again and I can't wait to see
what 2009 has in store for us all!
My fault - I used graphics-magick-compat-dev instead of image-magick-dev.
It works now.
Another question: What about cmake? It does not seem to work. Is there
no support for cmake as of now?
Cory K. schrieb:
> Henning Meyer wrote:
>> I'm trying to experiment with the tracing, but unfortunatly I cannot
>> even build inkscape from SVN/Trunk.
>> This is the error I get:
>> extension/internal/bitmap/level.cpp &&\
>> mv -f $depbase.Tpo $depbase.Po
>> extension/internal/bitmap/level.cpp: In member function »virtual void
>> extension/internal/bitmap/level.cpp:23: Fehler: »class Magick::Image«
>> hat kein Element namens »level«
>> make: *** [extension/internal/bitmap/level.o] Fehler 1
>> make: Verlasse Verzeichnis
>> make: *** [all-recursive] Fehler 1
>> make: Verlasse Verzeichnis '/home/hmeyer/devel/inkscape/trunk/inkscape'
>> make: *** [all] Fehler 2
>> For more details look at:
>> The same happens with SVN/Release_0_46_0.
>> What am I doing wrong?
>> Thanks for your help,
> Odd. As of *right now* trunk pulls and builds fine for me. Maybe pull a
> fresh copy?
> -Cory K.
I had a good look at the filters-comptrans-01-b test, and it appears
that the W3C's reference image is wrong for this test as well (earlier I
found the same for their Gaussian blur reference image). I have no idea
what the problem is and whether or not the reference is indeed wrong or
that it is some weird color space issue or something, but for the moment
I'm assuming that Inkscape's output is right. I again filed an issue in
the W3C issue tracker.
I'm trying to experiment with the tracing, but unfortunatly I cannot
even build inkscape from SVN/Trunk.
This is the error I get:
mv -f $depbase.Tpo $depbase.Po
extension/internal/bitmap/level.cpp: In member function »virtual void
extension/internal/bitmap/level.cpp:23: Fehler: »class Magick::Image«
hat kein Element namens »level«
make: *** [extension/internal/bitmap/level.o] Fehler 1
make: Verlasse Verzeichnis
make: *** [all-recursive] Fehler 1
make: Verlasse Verzeichnis '/home/hmeyer/devel/inkscape/trunk/inkscape'
make: *** [all] Fehler 2
For more details look at:
The same happens with SVN/Release_0_46_0.
What am I doing wrong?
Thanks for your help,
Right now, when you have Shape: Clipboard enabled, but nothing on the Clipboard, then you literally draw a blank. It can be very confusing upon start-up, especially since the warning message isn't in a very visible position. Users are bound to get confused if they're unfamiliar with the Shape feature, I thought there was something wrong with my development build at fist.
Here's a rather simple solution: when there's nothing on the Clipboard, then have a default where the resulting path is a normal path with no shape applied. Problem solved. The warning message (Nothing on the Clipboard) can still be displayed.
I see a significant regression in rendering speed for some days now. I
have build backups from Nov 07 and Dec 08, when I open the same file,
the newer build needs approximately 4 times more time to display the
file, zoom, scroll etc. than the older build. This makes editing of
large files almost impossible. Operations like selecting or moving items
on canvas likewise behave very slow.
What could be the reason for this? Any ideas?
Running the rendering tests again this week I encountered a regression
in the rendering of filters-comptran-01-b (from W3C SVG test suite).
This test contains four rectangles with the same gradient, one without
any filter and three with three different component transfer filters.
Last week the four rectangles in the filters-comptran-01 test were still
rendered with the wrong colours, but they were rendered. This week two
of them are not rendered anymore... As far as I can tell the component
transfer code wasn't touched during that time though, so I have
absolutely no idea why this suddenly happens.
Now the question is, should a bug be reported? And if so, what is this
the actual bug? As far as I can tell feComponentTransfer isn't supposed
to work anyway, so filing a bug seems a bit pointless at this point.
However, as it doesn't appear to be related to a change to the component
transfer filter it might actually be an unrelated bug in disguise.
So, any ideas on what could be causing this?
I just ran the rendering tests again, and compared to last week there
were suddenly 16(!) new results. I've had a quick look at some of them
and they all seem to be regressions related to filter rendering
(affecting quite a lot of different filters). Could anyone who has
touched the general filtering code in the last week please recheck their
work? (I'm currently swamped with work, so I have no time to go after