I've found a little error in inkscape website. On page
http://www.inkscape.org/download/?lang=en in section Compiled packages
should be nightly builds, but nightly builds are available only for
Windows, other systems have only compiled stable versions.
Op Di, 12 augustus, 2008 01:11, schreef J.B.C.Engelen@...1578...:
> Often it is not needed to add to_2geom/from_2geom, so please don't!
> The conversion goes automatically between NR::Point <=> Geom::Point and
> NR::Matrix <=> Geom::Matrix.
> Only ambiguities need a little more guideance:
> void some_function(NR::Point nr)
> Geom::Point geom;
> Geom::Point ambiguous = nr - geom;
What about methods that require parameters by reference for getting data
both in and out? Will the implicit casting work correctly for those too?
Maybe I should just try that myself; there are quite some snapping calls
requiring Geom::Point& (without being const). It would be great if I could
just pass a NR::Point. So far I've used dummy variables for that.
It's quite cumbersome indeed to transfer everything to 2geom. Last weekend
I had a shot at the snapping code, but I have caused some regressions
which need to be fixed first.
I guess Johan could still use some additional hands.
Here is the example showing how limits+randomness work:
I took my ideas and ideas from Steren. This hopefully resolves my issue
with the concept of "randomness" which wasn't clear to me exactly how it
should act (even when I was convinced that I wanted such parameter).
The mechanics for the rest of attributes (S, L and O) and dimensions
(rotation and scale) is exactly the same.
Note that when randomness is set to 0, the value is always |(max-min)|/2
(it's an absolute value for cases where min>max).
I've to revamp a bit the toolbar for this tool, since with these
changes some of the buttons can be scrapped (like scattering radius).
It lacks a way to select an original for spraying it. I thought about
a button "pick original" in the main toolbar. When pressed the cursor
changes to the normal arrow to click on an object/group and from then
on that's the original (in clone mode all of the clones are linked to it,
in the other two modes the object is just used for spraying but not
linked to the sprayed items).
Any (better) ideas?
Another issue: clones inherit attributes so is not possible to set
these parameters. Un less there is a way to make clones where
the only feature inherited is the shape.
I just started mass converting to Geom::Point, but then it struck me
that this will conflict with many changes other people are creating.
So I think it is best not to mass convert. It is the same with
Let me know what you all think.
NR::Point contains cast methods, so Geom::Point and NR::Point are
interchangeable in 90% of the cases. It would help a lot if you'd just
change NR::Point to Geom::Point in a line you are editing.
I've been talking to Johan about the directory structure used by the
rendering tests (in gsoc-testsuite/tester/testcases). The following
directories currently exist:
- basic: a few tests that test Inkscape's SVG rendering capabilities
(four of them are really quite "basic", the fifth is perhaps not very
- bugs: some tests from bug reports
- complex: currently just an LPE test
- svgtestsuite-1.1: a selection of tests from the W3C SVG test suite
If anyone has any suggestions for restructuring basic/complex, that
would be great, they seem a bit awkward. The original idea was that
basic just tests general SVG features.
Hi again. I just uploaded the GUI for the advanced options:
Is a bit over the top and some of the combinations may not
have a lot of sense in the end.
- The checkboxes allow the change of the attributes. Is
one is not activated it means the sprayed items will have
that feature the same as the original, unaltered.
In the case of spacing (which is not an attribute) I don't
know how this should work.
- Scale allows any value, positive or negative, as this will
allow the motif to be bigger or smaller than original.
- Rotation (and Hue) are always positive and the min can be
higher than the max. Why you ask? because if this is not
allowed, some configurations will be unavailable. If you want
items to be rotated between 15-345º (a margin of 330º),
you would use min=15º and max=345º.
But what if you want them rotated on the
other sector (345-15º=30º)? In that case you would
use min=345º and max=15º.
- X and Y spacing are there but I'm not sure of what units to use.
Should it be a % of the stroke width on each axis? What
behavior do people expect for spacing? I can't make
my mind right now.
- The color variation is activated independently for the
stroke/fill for each HLSO attribute. With the intention
of making the color selection easier and faster, I've
placed two color swatches (on the min and max columns)
so the user can call the color selector and pick the color
or insert values manually. Again, for the same reasons,
the min value can be higher than the max.
- I'm not exactly sure how "use lightness from background"
and "tablet pressure" does interact with the rest of the
settings. My idea is that these two should vary the attribute
between the set limits. But randomness doesn't make much
sense when using a tablet or the lightness since you would
want that attribute to be controlled and not random. Maybe
the Randomness spinbox should be deactivated when
"use lightness..." or "tablet" are checked.
PS: I think my HD is dying :(
The rotate left/right and flip horizontal/vertical buttons are so close
to each other on toolbar but behave different on multiple selected objects.
When selected multiple objects and rotating, all objects rotate around
their centre. To have them rotate as one, you first have to group them,
When flipping multiple selected objects, they already flip as group and
see no option to flip these by themselves.
I think these should behave similar. Most of other programs treat
selection as group, and this is what I first expected of Inkscape. But
considering the fact that grouping and rotating is quite easy, so having
these actions both per object would make these actions more general and
therefore more useful.
And to mention, I would only file a bug, no actual coding yet, Inkscape
codebase is a lot like Chinese for me (refering to something ultimately
Also, thanks for this good program
Although I really didn't want to do more work on those two outputs,
I was curious how 2geom's transforms worked, so I spent the day updating
POV and JavaFX output.
Ok, I think that -this time- I am finished with the javafx stuff, and I'll
let someone take it from here.
Here is how our svg Tiger renders in javafx:
I tested the POV output on POVRay 3.7a, and it seems to work fine.
It is recoded to be recursive rather than iterative. Some POV users
needed it to preserve groups, so this should help.