Parkinbot wrote

Sorry, I was wrong in this. Notepad guesses utf8 from the file content.

--
View this message in context: http://forum.openscad.org/After-changement-it-doesn-t-work-any-longer-use-seems-to-work-the-wrong-way-or-work-not-any-more-tp20017p20064.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

String literals in OpenSCAD are unicode, not UTF8 so it should be:

import("\u00f6\u00e4\u00fc.stl");

That produces the correct error message but still doesn't work.

On 12 January 2017 at 21:18, Parkinbot rudolf@parkinbot.com wrote:

without knowing the source code at all, I tracked down the these lines in
https://github.com/openscad/openscad/blob/master/src/import_stl.cc#L60
which open a file for stl import.

reading the following stackoverflow issue, points to the cause of the
problem (and its solution).
http://stackoverflow.com/questions/821873/how-to-open-an-stdfstream-ofstream-or-ifstream-with-a-unicode-filename

--
View this message in context: http://forum.openscad.org/After-changement-it-doesn-t-work-any-longer-use-seems-to-work-the-wrong-way-or-work-not-any-more-tp20017p20066.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

So import needs to use the 16 bit stream ctor. include and use need to
convert from UTF8 source code to Unicode first. I.e. they need to mimic the
string literal functionality in < > the same as in quotes.

On 12 January 2017 at 22:26, Parkinbot rudolf@parkinbot.com wrote:

Basically yes, unfortunately getting this to work across
all platforms makes it a bit more complicated (e.g. the
solution linked in the previous messages is not available
on other platforms).

I guess it's now at least clear, that the issue is related
to https://github.com/openscad/openscad/pull/1296

I'll add a link to this discussion to the github issue...

ciao,
Torsten.

You can use qt as a portability abstraction layer. Use QFile to open the
file. The filename is passed as a QString. Use QString::fromUtf8() to
construct the filename argument.

On Friday, 13 January 2017, Torsten Paul Torsten.Paul@gmx.de wrote:

On 01/13/2017 03:00 PM, doug moen wrote:

No, not at this point. The core is supposed to not depend on Qt.
I think that's valuable feature worth preserving.

ciao,
Torsten.

On 01/13/2017 06:49 PM, adrian wrote:

Considering the large number of requests for either a non-GUI
dependent version or a libopenscad, I have to disagree. Also
Qt is not some kind of magic thing that just solves all platform
issues. In this specific case it would help probably, but there
are also other solutions.

ciao,
Torsten.

I misunderstood the role of QT in OpenSCAD. I didn't realize that it is not
to be used in the core.

In that case, you could use boost::filesystem::ifstream to open the file
and boost::filesystem::path to represent the UTF-8 filename argument. The
advantage is that this API is part of C++17, so when OpenSCAD migrates to
C++17, you can switch to using std::filesystem. The disadvantage is that
the API is less straightforward than QT5. Here is a discussion about
constructing a filesystem::path from a UTF-8 string:

http://boost.2283326.n4.nabble.com/boost-filesystem-path-as-utf-8-td4320098.html

Another approach is that the core uses an abstract interface for opening
and reading files, and the client implements that interface. Kind of like
the outputhandler abstraction used by the core to write ECHO, WARNING and
ERROR messages to the console. Then the client could use QFile to open
included and used files, without polluting the core.

On 13 January 2017 at 12:56, Torsten Paul Torsten.Paul@gmx.de wrote: