DXF export fixed to 96 dpi, should use user unit scale

Could you please attach a test case to ease further investigation of the reported issue?

Of course, here it is.

Anyway I'm looking a bit more into it, and it seems unittouu and uutounit in inkex.py are not working properly, so it would be good to fix that first. Other extentions like measure.py are now working around that with a lot of hassle.

unittouu and uutounit only work correctly when the user unit is equal to one of the base units.

On 2015-12-12 17:32 (+0100), Piers Titus van der Torren wrote:
> unittouu and uutounit only work correctly when the user unit is equal
> to one of the base units.

This issue is tracked in
* Bug #1508400 “inkex.py: support arbitrary (but uniform) document scale (0.92)”
  https://bugs.launchpad.net/inkscape/+bug/1508400

I believe this bug is fixed by the patch proposed in:

https://bugs.launchpad.net/inkscape/+bug/1672066/comments/3

I would love to see a fix for this, that fixes it for all affected extensions.
Perspective/Envelope extensions stopped working in 0.92 and higher :-(

>>I would love to see a fix for this, that fixes it for all affected extensions.
>> Perspective/Envelope extensions stopped working in 0.92 and higher :-(

could you attach an example of this, these two extensions appear to be working for me on Windows 10, Inkscape 0.92.1 r15371

as far as I know, the original bug report was fixed in :
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15590

Thanks, Alvin. Attaching example for Perspective.

Started 0.92.1 with default new document, English language, drew the four-node path, typed the text and converted to path, ungrouped, combined, selected both, Path>Modify Path>Perspective, got that result (LM18.1, self-compiled version r15371 (not identical to release version, but I think it was only string changes)).

thanks for the file. This is very strange. I am unable to reproduce the problem using your file. I am attaching an edited version of your file. I copied the quadrilateral and also copied the text and applied the perspective extension and got the result in red, which appears to be good.

I wonder if you could confirm that your code is identical to mine. I have the results:
 Directory of C:\Program Files (x86)\Inkscape\share\extensions

02/13/2017 07:46 PM 632 perspective.inx
02/13/2017 07:46 PM 6,700 perspective.py

Thank you, Alvin. As Windows and Linux builds were created at different times, I think an md5sum makes more sense (my files are one day younger than yours):

da14901f71ce5cc72bc3d98c9f3f6a6b perspective.inx
b659615fc8890581281914aa91ef3fdc perspective.py

Perhaps it's also a preferences issue? Attached, in case.

sorry, I have no idea how to do a md5 sum, not something that happens on Windows.
attached is the python code I was using, from Inkscape 0.92.1 r15371

okay, now my curiosity is roused. I downloaded a program called WinMD5 for doing md5 sums. It appears that my md5 sums are identical to yours for these files. Also, I do not believe there is anything in the preferences that could affect this behavior, so I cannot explain why the extension is behaving differently for you than for me.

Could it be a locale issue...? I'm using
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"

>> Could it be a locale issue...?
it seems unlikely, since everything has already been converted to a path. I wonder if you could also check your inkex.py file to see if it is the same as mine? The info on mine is:

02/13/2017 07:46 PM 15,155 inkex.py
md5 = 8358bdc6acb5d6fdec133a5aad679b37

another possible test: I have created an svg file (attached here) with a quadrilateral and a pentagon. Then I duplicated these on the right hand side. On the right hand side I applied the perspective extension. Could you apply it on the left to see what you get?

Checksum is identical. Result looks wrong (Inkscape 0.92.1 r15371)... So weird...

yes, indeed, very strange. one more possible test: a lot of the scaling in the extension is done using a bounding box calculation, which comes from a query command which can be executed in DOS.
Attached is the result of this query command on my machine. Could you check to see if yours is the same? I believe it is only the three paths that are of interest:

C:\Program Files (x86)\Inkscape>inkscape --query-all \windows\temp\perspective_extension_result.0.92.1.svg

svg8,160.69677,338.71766,266.78208,475.25519
layer1,160.69677,338.71766,266.78208,475.25519
path3680,176.19799,338.71766,224.74687,227.604
path3712,160.69677,724.90987,259.50316,89.06298
path3760,163.50219,423.213,263.97667,263.04558

$ set INKSCAPE_PROFILE_DIR="/home/maren/.config/inkscape0.92"; /opt/inkscape_0.92.1/bin/inkscape --query-all /tmp/perspective_extension_result.0.92.1.svg

svg8,160.69677,338.71766,266.78208,475.25519
layer1,160.69677,338.71766,266.78208,475.25519
path3680,176.19799,338.71766,224.74687,227.604
path3712,160.69677,724.90987,259.50316,89.06298
path3760,163.50219,423.213,263.97667,263.04558

(identical...)

thanks for testing. In that case I have run out of ideas. I know of two other bugs that affect this extension, but neither of them is applicable here.
https://bugs.launchpad.net/inkscape/+bug/1653650
https://bugs.launchpad.net/inkscape/+bug/1664029
I also know of one bug that was apparently caused by an obsolete Python file, but that has been subsequently resolved:
https://bugs.launchpad.net/inkscape/+bug/1673349

Yes, I even tested by modifying the .inx file - it's definitely the correct one... Thank you for investigating, Alvin.

perspective problem may perhaps be related to Bug #1701553.
There is something very unexpected happening in the function inkex.unittouu which is used quite heavily when scaling various Python extensions.

@Maren - you don't happen to have an older version of Inkscape installed on your system, which is in $PATH as seen by the python extension script (which then would be the inkscape binary that will be spawned by the extension to query the dimensions of the paths to be perspectively deformed)?

@Maren - if I force a local installation of Inkscape 0.91 (90dpi) to be the one spawned by script extensions of Inkscape 0.92.1 (96dpi), I can reproduce your result from comment #14 (but only then). In my understanding, this is more a "side-effect" of working with several custom installations of Inkscape alongside a stable official package, without properly vetting all aspects of that (rather than a bug in one specific extension script).

I would recommend to carefully adjust $PATH in any launcher scripts you might use for local inkscape builds installed into a custom prefix; e.g. to prepend the 'bin' folder of the custom prefix to $PATH.

Ha, thank you, V!!!

This addition would probably also be useful to add into the Inkscape README, where it suggests running Inkscape without installation. I'll adjust my launchers, and will make a merge request to adapt the README, too (tonight).

No wonder that Alvin wasn't able to reproduce... :/ Sorry :-( , I didn't think of this possibility...