Quantcast

extensions handling user-units and query-all in 0.92

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

extensions handling user-units and query-all in 0.92

Pelle Nilsson
Hi,

I just joined this list because after asking about extensions and
handling of dpi etc in 0.92 on the Inkscape forums and on Launchpad I
got several recommendations to bring it up with you developers here
instead. (I should probably have lurked here a long time to keep
updated about changes happening to Inkscape before major releases. My
extensions have been online since 2008.)

Either I am confused about how user-units are supposed to work (and my
extension is even more confused) or there is a bug in Inkscape
(possibly in inkex.py?).

http://www.inkscapeforum.com/viewtopic.php?f=29&t=31525
https://answers.launchpad.net/inkscape/+question/431543
https://bugs.launchpad.net/inkscape/+bug/1654907
https://www.boardgamegeek.com/thread/299033/inkscape-extensions-boardgame-development

For testing I created a rectangle in 0.91, a 1x1-inch square at -3
inches x (I only bother with the x-coordinates in the following).
Inkscape UI reports that it is at -270px. If I  transform it by
translate(270) it ends up at x=0, as expected.

It also works in 0.92. Inkscape UI now reports -288px, but still a
translate(270) works as expected, so Inkscape internally correctly
understands that the user-unit in this document is 1/90 inches (I
confirmed by calculating svg width and viewBox that it is indeed
that).

But the countersheetsextension running in 0.92 on a document from 0.91
gets confused and translates things too far. If the document was
created in 0.92 it works (user-units for an A4 for instance being 1mm,
and it translates properly). The extension works by reading
coordinates using --query-all, and I had to make a small change to
even support 0.92-documents in 0.92 (see
https://github.com/lifelike/countersheetsextension/commit/aa454f5117fbd457d4d54f47a86343d7d159bebf),
but this fails on a document created in 0.91. The calculations, done
using unittouu, ends up with values as if the user-units were 1/96
inches, so in the example above the extension outputs translate(288),
and the rectangle is translated 18 units too far to the right.

So what I think is going on is that inkex.unittouu fails to properly
calculate coordinates in user-units if they do not match some of the
pre-defined values, but Inkscape internally does a better job?

Trying to figure out a work-around. Perhaps write my own function to
calculate user-units instead of using unittouu, or somehow detecting
that the document was created using 0.91 (although I guess it will
still fail for documents with any other possible user-unit lengths
that might exist out there?)? Or maybe I just use the API in inkex the
wrong way and what I try to do should already be possible?

--
/Pelle

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...