measure path command has major problems on my drawings

Bug #406662 reported by Steve Swafford
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Medium
Unassigned

Bug Description

I recently downloaded the .47 pre 1 version. the first problem I reported had to do with printing, it only happened once, so i think that was on my side.

now something serious, I think.

for my computer, I have a drawing of a womens 1-piece swimsuit that I am designing.

I have made sure my units of measure and base units were all the same, and decided to measure the path using the "measure path" command.

well some things that should be around 18 cm are measuring at 43 mm. another line that is used in two different places and copied from one place to the other measures at 4.0m and 19.8mm in two different locations. the same line just copied over.

I have another computer with versions .46 and I measured something there and it worked like a charm, all of the measurements were within 1-2mm of anticipated length.

when I run the Measure path command on .46 it is almost an instant report of the length. When I measured that line the is both 4.0m and 19.8 mm, a dialog box came up and said something like "measure path working" and took almost 15 seconds to put up the dimensions. during that time in the command line at the bottom of the screen, where running programs are displayed, the tab for the measure path command was flickering constantly during the time of the measure path working dialog box popup and the cpu usage meter went crazy and spiked on both cpu and memory

one small line that is a little over 2 cm long, when I tried to measure the path for it, it took over a minute and then the flickering tab stopped flickering and the program, .47 stopped responding all together and had to be shut down with the task manager.

I will be uninstalling .47 and reinstalling .46 this evening.

I am running a pentium 4 machine 2.6 ghz, 760mb of ram, with xp home 2002, service pack 2,

I will answer any questions I can,

thanks for all you do in writing and providing such a wonderful program in Ink Scape

thanks again

Steve

Revision history for this message
Alvin Penner (apenner) wrote :

could you attach an .svg file that illustrates the problem?

Revision history for this message
jazzynico (jazzynico) wrote :

Not reproduced on Windows XP, Inkscape rev. 22056.
Measurements are ok, and it take a very short time to process.
As Alvin wrote, it would be very helpful to have a copy of your SVG.
Thanks!

tags: added: extensions-plugins
Changed in inkscape:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
su_v (suv-lp) wrote :

I don't know if it's related but I can't run 'measure.py' from inside Inkscape at all.

Issue: python fails in 'locale.setlocale(locale.LC_ALL, '')'

Traceback (most recent call last):
  File "Contents/Resources/extensions/measure.py", line 34, in <module>
    locale.setlocale(locale.LC_ALL, '')
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/locale.py", line 476, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

I tried with 3 python verison (OS X python 2.5.1, MacPorts Python 2.5.1, 2.6.2). The strange thing is if I run the command outside of Inkscape (or the GLibc context?) like:

LeWitt:~ suv$ which python
/Volumes/blue/mp/bin/python
LeWitt:~ suv$ python --version
Python 2.6.2
LeWitt:~ suv$ python -c "import locale; print locale.setlocale(locale.LC_ALL, '')"
en_US.UTF-8
LeWitt:~ suv$

It is the only python extension which depends on locale settings. I tried with different LANG settings in the launcher script, but nothing so far lets python read the current locale setting when run in the context of Inkscape.

Inkscape 0.46+devel 22011, OS X 10.5.8

Python bug: <http://bugs.python.org/issue1699853%3E> "locale.getlocale() output fails as setlocale() input "

Revision history for this message
su_v (suv-lp) wrote :

Retracting above comment - today I can't reproduce the error with a current build (rev22062) and setting PYTHONHOME for python 2.6. It seems not to be consistently reproducible, as other comments (via google search) suggest as well.

Revision history for this message
G. Steel (germsteel) wrote :

Hello,

I am experiencing this bug. Inkscape 0.47pre4 r22446, built Oct 16 2009
running on OS X 10.6.2 python 2.6.2 I was having problems running
Extensions > Visualize Path > Dimensions so I used the default write to link to python
2.5.4. Dimensions extension works now but
I can't run Extensions > Visualize Path > Measure Path

Traceback (most recent call last):
  File "Contents/Resources/extensions/measure.py", line 34, in <module>
    locale.setlocale(locale.LC_ALL, '')
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/locale.py", line 478, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

I tried setting the locale as described by SUV above but I still get the same error.

Thx

Revision history for this message
su_v (suv-lp) wrote :

<off-topic>
> Inkscape 0.47pre4 r22446, built Oct 16 2009

why don't you use the current release (0.47 from <http://sourceforge.net/projects/inkscape/files/inkscape/0.47/>) or a recent devel-build (0.47+devel from <http://inkscape.modevia.com/macosx-snap/?C=M;O=D>) instead of a long out-dated and unstable prerelease version?
</off-topic>

I recently happened to test this issue again - with the offical 0.47 package on OS X10.5.8 using the Apple's Python 2.5.1. This time it the measure script works without error after modifying the launcher script like this:

$ diff -u inkscape inkscape-locale.sh
--- inkscape 2010-05-07 03:29:28.000000000 +0200
+++ inkscape-locale.sh 2010-05-09 03:15:13.000000000 +0200
@@ -121,6 +121,7 @@
 # to crash on startup in locale_from_utf8().
 export LANG="`grep \"\`echo $LANGSTR\`_\" /usr/share/locale/locale.alias | \
  tail -n1 | sed 's/\./ /' | awk '{print $2}'`.UTF-8"
+export LANG="en_US.UTF-8"
 echo "Setting Language: $LANG" 1>&2

 sed 's|${HOME}|'"$HOME|g" "$TOP/etc/pango/pangorc" > "${HOME}/.inkscape-etc/pangorc"

Revision history for this message
su_v (suv-lp) wrote :

attaching diff file for Inkscape 0.47 22583, built Nov 24 2009

steps to apply the patch:
$ cd /Applications/Inkscape.app/Contents/Resources/bin
$ cp inkscape inkscape-orig.sh
$ patch < ~/Downloads/406662-locale-047.diff

Note: with this patch Inkscape.app will no longer honor the language settings in OS X 'System Preferences > International > Language'. You can still change the UI language of Inkscape in 'Inkscape Preferences > Interface > Language'.

Revision history for this message
Elia Vecellio (eliavecellio) wrote :

@~suv: THANKS A LOT!

I was having the same problem trying to use the Measure Path tool (to get area of a shape) under the latest development build (0.47+dev9407), where I would get the Python-related error: unsupported locale setting (identical to the error ~suv reported last year).

I had this same problem on two OS X 10.5.8 machines (one PPC, one i386). On the PPC machine, using a dev build from a week ago, I tried doing a bunch of stuff like updating Python etc, but had no luck. Today, I tried the latest dev build on the i386 and had the same problem, but ~suv's patch worked perfectly to resolve the issue. I will try it out on the PPC machine too.

I am in Australia, so I wonder whether Inkscape/Python doesn't like the Mac regional settings set to anything but English - USA? I notice that Inkscape defaults the language to "System Default" so it might get upset by anything that isn't English - USA...

Anyone else having the "unsupported locale setting" error should try the patch... it seems like good stuff... but hopefully the actual cause of the problem will be rectified

Revision history for this message
su_v (suv-lp) wrote :

@Elia - if you look at the console messages when launching Inkscape.app (0.47 or devel builds), you'll most likely see these lines:

> Setting Language: .UTF-8
> Gtk-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale.

i.e. the launcher script fails to create a valid $LANG string. IMHO this is the reason why the system-installed Python subsequently fails on certain functions that depend on correct locale settings. See also my comments in Bug #476678 “Mac OS X: Fails to get locale in Japanese” about the possible cause and a (unfinished) proposal how to alternatively parse the language settings from the OS X system preferences of the current user.

The patch I added in comment #7 is not a good solution because it drops any result from parsing of the current user settings in the 'International' preferences pane.

Revision history for this message
su_v (suv-lp) wrote :

In reply to <https://answers.launchpad.net/inkscape/+question/117450>:

@David M - attaching launcher script with applied patch for workaround (see comment #7)
replace this file inside the application package:

 Inkscape.app/Contents/Resources/bin/inkscape

(take care that the browser or finder does not add a hidden file name extension to the attached file 'inkscape')

Revision history for this message
su_v (suv-lp) wrote :

Note:
Do not use the file attached to comment #10 with Inkscape 0.48 or later (it is only compatible with Inkscape 0.47).

Revision history for this message
Kris (kris-degussem) wrote :

Issue not reproduced either on vista 64 bit, trunk r11598.
Also no further feedback received.
Hence, closing as invalid (separate issue on OSX will be taken care off separately).

Changed in inkscape:
status: Incomplete → Invalid
Revision history for this message
su_v (suv-lp) wrote :

Workaround for osx issue as discussed in comments #3-12 committed to trunk in r11765 and backported to 0.48.x (r9917):
- add console messages to help debug incorrect LANG settings
- use 'en_US.UTF-8' fallback setting for LANG if currect detection fails
  addresses issues with failing python extensions which use setlocale()

Note: OS X package of Inkscape still needs more robust language detection (e.g. bug #617079, bug #476678).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.