Sorry if this has been reported before, but since sourceforge do not
allow the public to search their mail archives, or google to index their
archive I have no way to check...
I have been using the most excellent Inkscape to draw some simple
graphics that I then load into the Gnome canvas - I am using my own
(simplistic) Python code to parse the SVG via sax, and end up loading
all of the coordinates into CanvasBpath shapes.
The problem I have is that the coordinates bear little relationship to
those inside Inkscape. It appears that Inkscape is internally doing an
invisible translate and scale to make the paths appear on the page.
This is befuddling not only me, but my code as well. I end up with with
coordinates in paths that are off the page while clearly the entire
document is on the page (inside Inkscape).
Note also that I always ungroup all objects whenever I scale or
translate in Inkscape to avoid the creation of a transform attribute.
Should there be some way to get Inkscape to "normalise" object
coordinates so that they match the size of the document? After all, the
is what is being displayed.
On Mon, 23 Aug 2004, Dave Cole wrote:
> Sorry if this has been reported before, but since sourceforge do not
> allow the public to search their mail archives, or google to index their
> archive I have no way to check...
You can go to gmane.org to search the archive of a newsfeed I set up
there early on in the project that should have all inkscape-devel@ and
inkscape-user@ mails since the start.
> Should there be some way to get Inkscape to "normalise" object
> coordinates so that they match the size of the document? After all, the
> is what is being displayed.
I don't know if it is documented, but there are ways to convert the
coordinates into sanity. Yes you're right that the way they work is a
little screwy; it's something we inherited - several developers have
worked to sort it out but it is pretty thoroughly interlaced through the
code. Hopefully one of them can give a clearer answer.