View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001930||Drawing||Bug||public||2015-01-23 20:18||2015-01-25 00:49|
|Target Version||Fixed in Version||0.15|
|Summary||0001930: Export a page to an SVG file and UnicodeEncodeError|
|Description||It looks like default ASCII encoding is used ATM:|
|Steps To Reproduce||Insert any non-ASCII character like ü in export page file name.|
|Tags||No tags attached.|
I can't reproduce the problem when saving a Drawing.
Can you pleas elaborate, on what you mean by "page"
OS: Debian GNU/Linux 7.8 (wheezy)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.15.4519 +241 (Git)
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 4.0.0a
OCC version: 6.8.1.dev-27a6612
On Windows it works for me, under Ubuntu it doesn't work either.
> Can you pleas elaborate, on what you mean by "page"
When you create a Page object in the drawing workbench, select it in the tree view and then invoke the export command of the drawing workbench.
When entering non-ASCII characters you get this error:
Traceback (most recent call last):
File "<string>", line 1, in <module>
<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode characters in position 5-7: ordinal not in range(128)
Stack Trace: Traceback (most recent call last):
File "<string>", line 1, in <module>
Thanks, werner. Now i got it.
void CmdDrawingExportPage::activated(int iMsg)
This one is indeed missing in the ugly workaround.
we need to address
I see the culprit is hardcoding locale environment variable LANG=C instead of using system default locale on Linux. This was done to solve a bug with OCC expecting to always get correct decimal mark but this solution does affects DW SVG exporting. When non-ASCII character is used for file name export operation will fail.
I am still wondering as this is Linux specific locale issue why setting just LC_NUMERIC did not work to overcome both issues on Linux?
> I am still wondering as this is Linux specific locale issue why setting just LC_NUMERIC did not work to overcome both issues on Linux?
since we are using multiple frameworks which might behave differently on different platforms, i was concerned, because apparently we need to use putenv to modify the environment. I wanted to know why the putenv is required and if there is a cleaner way to achieve our goal.
Apparently there isn't. So I'm for just using putenv to set LC_NUMERIC=C.
If i understand you correctly you would like to use std::locale::global (C++) to set global (numeric) locale on Linux. This way you could use set locale from both C and C++ functions.
It looks like this bug was just fixed and i just added a note 2 minutes before it was closed.
Probably this was noticed but just to be on the safe side i decided to reopen this issue report.
If mentioned last note does not change anything regarding this issue report feel free to close it as fixed and anyway thanks for fixing it in the first place!
||I tried the c++ version and did not worked out as expected. please have a look at 0001852 for the details.|
I see. Feel free to close this issue report as fixed.
|2015-01-23 20:18||triplus||New Issue|
|2015-01-24 10:17||shoogen||Relationship added||parent of 0001852|
|2015-01-24 10:19||shoogen||Note Added: 0005696|
|2015-01-24 10:23||shoogen||Note Added: 0005697|
|2015-01-24 10:26||shoogen||Note Edited: 0005697||View Revisions|
|2015-01-24 10:33||wmayer||Note Added: 0005698|
|2015-01-24 10:50||shoogen||Note Added: 0005699|
|2015-01-24 10:59||shoogen||Note Edited: 0005699||View Revisions|
|2015-01-24 11:01||shoogen||Note Edited: 0005699||View Revisions|
|2015-01-24 11:39||shoogen||Note Added: 0005700|
|2015-01-24 16:55||triplus||Note Added: 0005712|
|2015-01-24 19:06||shoogen||Note Added: 0005717|
|2015-01-24 22:46||triplus||Note Added: 0005719|
|2015-01-24 22:48||shoogen||Status||new => closed|
|2015-01-24 22:48||shoogen||Assigned To||=> shoogen|
|2015-01-24 22:48||shoogen||Resolution||open => fixed|
|2015-01-24 22:48||shoogen||Fixed in Version||=> 0.15|
|2015-01-24 23:05||triplus||Note Added: 0005722|
|2015-01-24 23:05||triplus||Status||closed => feedback|
|2015-01-24 23:05||triplus||Resolution||fixed => reopened|
|2015-01-24 23:10||shoogen||Note Added: 0005723|
|2015-01-24 23:23||triplus||Note Added: 0005725|
|2015-01-24 23:23||triplus||Status||feedback => assigned|
|2015-01-25 00:49||shoogen||Status||assigned => closed|
|2015-01-25 00:49||shoogen||Resolution||reopened => fixed|