And please be sure to file a bug/feature request at
In the end there will obviously always be cases where Inkscape is too
slow, but Inkscape could most definitely be faster in some cases. And
just locking/unlocking the layer should (from an intuitive standpoint)
NOT cause such a big pause.
Dave M G wrote:
> Thank you for responding.
>> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs
>> of RAM. It makes no difference. I think it's all the looping through those long
>> lists of nodes....
>> You are doomed. Unless you can simplify or chop-up your comic page into frames
>> and assemble them later in Gimp.
> Okay. While it's a little disappointing that there isn't a way to
> optimize the file for better performance, it's good to know that at
> least I'm not doing something wrong.
> I'll export the paths into a PNG and handle the colouring in Photoshop
> or GIMP. It means committing to rasterizing the images sooner in my
> process than I had hoped, but hey, life is full of compromises.
I write a German pdf user manual via inkscape 0.46. In this book are
screenshots of Inkscape. I would like to publish the book.
I'd like to have your permission. *Do I need a permit? *Please, who is
my contact? Who can help me here?
Please inform me, thank you.
after freshly installing Inkscape (rev. 21524), the Pen/Pencil tools
produce lines which are filled black but don't have any stroke. This
is very counterintuitive. The small info field in the toolbar (on the
right hand side) displays "Fill: None, Stroke: Black (000000/1)"
(these are indeed the values specified in preferences-skeleton.h for
the freehand tools). However, both in the Fill & Stroke dialog and in
the Preferences it says: "Fill: Unset, Stroke: Unset", and this
probably explains the strange appearance of the drawn lines. What's
happening here? Why are the values in preferences-skeleton.h not
correctly taken into account? I think this should definitely be fixed
Michael from LinuxFund asked me to announce on the list that another $500
have been raised by a donor for my work on the text bugs and new text
toolbar. I will be meeting Michael at LinuxTag Berlin end of this week.
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
Now to be more precise again : admitting I work with the future
corrected version of Inkscape, I select an object or a picture in my
document, I click on a filter in one of the lists in a Filters submenu
while the filters.svg file in Inkscape directory is the same than
today. Will Inkscape new version add to the filter the instructions
needed to display the filter like it displays in Inkscape today ?
Sorry, I am a visual person and not a coder (if I could I would... but
at the moment no time to go further in this direction I am afraid) and
I try to understand the most clearly I can because I must evaluate
which kind and amount of work will be needed to adapt the results of my
work if necessary.
Thanks for your patience and regards,
De : Jasper van de Gronde <th.v.d.gronde@...528...>
À : Ivan Louette <ivan_louette@...48...>
Envoyé le : Vendredi, 26 Juin 2009, 13h49mn 18s
Objet : Re: Re : [Inkscape-devel] Re : turbulence filters
Most definitely! Any existing work using filters will be rendered differently using other viewers or newer versions of Inkscape. How visible the difference is depends on the type of filter. And since the transfer function is highly non-linear there is really no other fix than adding the color-interpolation-filters="sRGB" property to the affected filters (which will make them look the same in other viewers as in Inkscape).
Ivan Louette wrote:
> Thanks. In fact my question is simple : will the coding changes to reach compatibility with other viewers and renderers affect the aspect of the already created works using filters, gradients and other features which causes problem ? Of course if doing some changes in filters numerical entries could help I would search actively how to do this, but if the problem stays deeper in Inkscape code I can't do anything.
I know that it might sound unbelievably silly, but no matter how hard
I try I can't get guides to rotate on canvas. The release notes
doesn't really explain how to do it. I tried all combinations of Ctrl,
Alt and Shift above rotation circle mark. So, any clue?
Is there any kind of Inkscape regression files that we can use for testing
I'm thinking about a collection of files that systematically incorporates
certain kinds of path effects, patterns, color management testing and so on
to make eyballing bugs easier.
*If there is none, here's my suggestion*:
For example, one file would be for testing the new "Path Effect Editor" and
could have 10 sample paths which each is using one of the available effects.
Beside each path, there's an bitmap to show what the path is supposed to
look like which makes it very easy to compare the desired path effect to the
At the same time, these files would be kinda educational, since the
instructions for producing each effect could be written on the canvas right
next to the paths.
*Here'**s the same type of files for Blender:*
"Regression files are .blend examples showing systematically all features we
test before doing a release. This is a good reference for bug hunting, but
also a valuable demo overview for new users.
Blender 2.49 regression suite (50+ demo files):"
Please find below a link to a survey related to my PhD research work to evaluate OSS usability improvement from OSS developer's point of view.
It shall not not take more than 5 minutes of your precious time.
Your identity is neither required nor recorded. The participation is highly valued and appreciated.
Thank you and Best Regards
Isn't our turbulence filter producing darker output than expected? The
attached svg file is borrowed from the w3c test suite, and also contains the
expected png output: our render looks draker.
I bumped into this trying to use turbulence as a displacement map: the
displacement always globaly shifts the image downward and to the right. This
is because the avarage value in each turbulence output channel is not 128
but much darker.
I think this is a bug... (maybe premuliplied alpha versus normal alpha color
Am I wrong?
I'm the guy who made the winning entry for the 0.47 "about screen"
contest (I actually noticed it today, I don't check deviantart that
often...). Thanks for choosing my picture!
I was wondering what's expected from me now. Are any modifications
needed? I'm open to suggestions!