You can use screenshot. But back to the issue, in other part of DrGeo, when saving/loading sketch, path or filename with accent, space are ok. So not sure what's going on. Hilaire Le 22/09/2014 22:15, Alexandre Bergel a écrit :

:-(

I will soon face the same problem I fear, when I will start my lecture…

Alexandre

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

The issue is already there https://pharo.fogbugz.com/f/cases/14054/Issue-with-path-with-accented-charac... I try to document it but it is odd, because for some other part in DrGeo I don't have issue with accented path. But should not the path be utf-8 encoded? Or is my fresh linuxmint box using non utf-8 filename, not it can't be. Hilaire Le 22/09/2014 22:20, Juraj Kubelka a écrit :

Can you create an issue? I am cleaning the fonts and in some case I could consider this issue. If it is problem only on Windows, I will need someone’s assistance.

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Le 22/09/2014 22:35, stepharo a écrit :

So I do not accept the title of your email. Simply I cannot.

Don't worry, it is a temporary cry/yield of frustration. -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Le 22/09/2014 23:14, phil@highoctane.be a écrit :

Also, sometimes things do look like "Téléchargement" but are still Downloads under the hood as the OS translates the UI.

Yes, I check within another path of my own like 'été', still same issue. Strange is I have no issue to search for sketch file with accent. Only when loading the font. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

I also find the way some problems are reported quite disturbing. How much testing did you do ? On which platforms ? I can do this (in Pharo 3) without any problems (we're talking about arbitrary Unicode characters in path names): ('/tmp' asFileReference / 'été') ensureCreateDirectory. '/tmp/été' asFileReference exists. ('/tmp/été' asFileReference / 'Ελλάδα.txt') writeStreamDo: [ :out | out << 'What about Greece ?' ]. ('/tmp/été' asFileReference / 'Ελλάδα.txt') exists. ('/tmp/été' asFileReference / 'Ελλάδα.txt') contents. And in a terminal, I get: $ ls /tmp/été/Ελλάδα.txt /tmp/été/Ελλάδα.txt $ cat !$ cat /tmp/été/Ελλάδα.txt What about Greece ? This is on Mac OS X. So this part fundamentally works in the image and on one VM. There might of course be problems in how paths are used in certain places or on certain VM/platforms. Sven On 22 Sep 2014, at 22:35, stepharo <stepharo@free.fr> wrote:

Hilaire

These are two days that after upgrading my iPhone, the recovery process crash. After two days trying I finally succeeded to upload my recovery to my iPhone and now my iPhone crashes continously at boot time. I get a nice sepia screenshot and it restarts. I will have to send my iPhone to Apple for real check. Just because I did an update!

So I do not accept the title of your email. Simply I cannot.

Do you imagine the billions injected into iPhone. So probably iPhone is one order of magnitude more complex than Pharo but the money injected into Pharo is our collective time and it is far from being an order of magnitude smaller than several billions.

Stef

On 22/9/14 22:07, Hilaire wrote:

...

Hello,

Tested on Linux, when I move DrGeo.app folder under hierarchy tree with accent characters (For example, /home/hilaire/Téléchargement/), loading font does not work

However font path seems ok: File @ /home/hilaire/Téléchargements/DrGeo.app/Contents/Resources. Inspecting this path, it looks like 'Téléchargements' is 8 bits, but it should be utf-8, right?

I think there are issue on Windows, as some user reported to me.

Holy shit.

Hilaire

so I stay with my 8Gb iTouch iOS 3 ; with no prospect of an upgrade, I am sorta worry-free. If only it were also a phone ... " Don't dial ... DO ! " ;-) [ this msg was last seen in my default font ] On 22 September 2014 17:35, stepharo <stepharo@free.fr> wrote:

Hilaire

These are two days that after upgrading my iPhone, the recovery process crash. After two days trying I finally succeeded to upload my recovery to my iPhone and now my iPhone crashes continously at boot time. I get a nice sepia screenshot and it restarts. I will have to send my iPhone to Apple for real check. Just because I did an update!

So I do not accept the title of your email. Simply I cannot.

Do you imagine the billions injected into iPhone. So probably iPhone is one order of magnitude more complex than Pharo but the money injected into Pharo is our collective time and it is far from being an order of magnitude smaller than several billions.

Stef

On 22/9/14 22:07, Hilaire wrote:

...

Hello,

Tested on Linux, when I move DrGeo.app folder under hierarchy tree with accent characters (For example, /home/hilaire/Téléchargement/), loading font does not work

However font path seems ok: File @ /home/hilaire/Téléchargements/DrGeo.app/Contents/Resources. Inspecting this path, it looks like 'Téléchargements' is 8 bits, but it should be utf-8, right?

I think there are issue on Windows, as some user reported to me.

Holy shit.

Hilaire

Le 23/09/2014 14:09, Damien Cassou a écrit :

I recently read documents about utf-8 encoding. In all of them, the author says that pathnames should be kept as is because you never know which encoding the filesystem uses. So, a filename should probably be a bytearray.

yes, but a #é should be encoded in two bytes. But although it looks strange, I am not sure it is the exact problem because I can use accented file name for sketch, but problem arise when loading a font. So may be the code loading a font. (cf my bug report) Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

On 24 Sep 2014, at 18:48, Benjamin Pollack <benjamin@bitquabit.com> wrote:

On Tue, 23 Sep 2014 08:51:54 -0400, Hilaire <hilaire@drgeo.eu> wrote:

...

Le 23/09/2014 14:09, Damien Cassou a écrit :

...

I recently read documents about utf-8 encoding. In all of them, the author says that pathnames should be kept as is because you never know which encoding the filesystem uses. So, a filename should probably be a bytearray.

yes, but a #é should be encoded in two bytes.

As noted in my previous message, "é" could be represented as either one or two Unicode code points, and these in turn could validly be either two or three bytes in UTF-8. My gut says that $é should be U+00E9, because otherwise you should have to use two Characters ($e and $´), but you could legitimately argue otherwise as well, and at any rate, #é could definitely be either. This is likely the core of the issue you're hitting.

Did you read the actual conversation in the issue ? https://pharo.fogbugz.com/f/cases/14054/Issue-with-path-with-accented-charac... It has been renamed and there is a fix (as a change set, not as a slice, yet). Basically, there was a primitive call into a plugin that failed to do encoding. Now regarding the issues you raised. Pharo does not do Unicode canonicalisation or any of that other fancy stuff (like categorisation, proper ordering and so on). This is another orthogonal and way more general issue. Regarding the pathnames encoding: if the OS itself does not know it, how can we ? I think that the current approach (assuming UTF-8) makes (the most) sense for a system that runs on multiple platforms. Sven

On 24 Sep 2014, at 19:09, Benjamin Pollack <benjamin@bitquabit.com> wrote:

On Wed, 24 Sep 2014 13:03:57 -0400, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

Did you read the actual conversation in the issue ?

https://pharo.fogbugz.com/f/cases/14054/Issue-with-path-with-accented-charac...

It has been renamed and there is a fix (as a change set, not as a slice, yet). Basically, there was a primitive call into a plugin that failed to do encoding.

No, I apologize; I missed the bug link. Thanks for reposting it.

...

Now regarding the issues you raised. Pharo does not do Unicode canonicalisation or any of that other fancy stuff (like categorisation, proper ordering and so on). This is another orthogonal and way more general issue.

Regarding the pathnames encoding: if the OS itself does not know it, how can we ?

That's actually the argument *against* using UTF-8 as the standard Pharo way to represent filenames--at least on Unix systems. If Pharo used ByteArrays to represent paths, with convenience methods for working with UTF-8 (since I do agree that's the most likely thing for a user/dev to want), then you'd be able to work with all files no matter what, *and* have a convenient way of doing so for the common case.

This is an old discussion, and I do see both sides of it. In terms of SCMs, Mercurial and Git both just say "it's a collection of bytes", whereas Subversion says "it's Unicode code points." This has some uncomfortable implications for both systems when working on multiple platforms.

Benjamin, I think I understand the concern / situation that you describe. But I fail to see how not-interpreting it and interpreting it in different encodings can work in practice, especially since your point seems to be that there is no meta information that gives a definitive answer. I would guess that other languages, say Java or Python, have some approach to handle this problem ? Also, since we are living with the current approach without much problems, I think the issue is not terribly pressing. Sven

Alain, On 24 Sep 2014, at 23:00, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 24/09/2014 19:09, Benjamin Pollack a écrit :

...

If Pharo used > ByteArrays to represent paths, with convenience methods for working with UTF-8 (since I do agree that's the most likely thing for a user/dev to want), then you'd be able to work with all files no matter what, *and* have a convenient way of doing so for the common case. Hi Ben, I strongly disagree with you on this point: using byte arrays (or byte strings) is a pain in an international context. The OS knows about its encoding: locale for unix, code page for windows. Windows code pages depends on country, for english windows 1252 (similar to iso-8859-1), for other european countries, other variations of 8859-xx... (welcome to ISO soup), same for unix.

Java uses UTF8 strings and dotNet uses UTF16 strings (don't know for Python) where chars are not bytes and they are not used as byte arrays but as Character arrays. Both do conversions from OS character set encoding to internal encoding for strings (paths and whatever).

There is already an UTF8 and UTF16 encoding support in Pharo, but the standard String class uses bytes, and lot of files, directories and system methods use ByteString class and that is the problem here. UTF8 encoding in Pharo encodes to a variable lenght ByteString, which is not the same as an (hypothetical) Utf8String where all (variable length) chars would be utf8 encoded. Using a new UTF8 or UTF16 string class could be a major rework, but taking a decision about about internal string encoding is needed. As Sven says, there is no emergency and you have a workaround, but perhaps using the existing WideString encoded as UTF16 (or UTF32?) in some well defined classes/methods could be a good start for this rework? IMHO the workaround of using utf8 encoded byte strings is not a good way to deal with this problem and should not be granted as "the solution".

The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code. You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing: http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing. Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before). Sven

On 25 Sep 2014, at 01:04, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :

...

Alain,

...

The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code.

You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing:

http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing.

Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before).

Sven

Very interesting ! It seems that most of what I was saying is already here :) I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a standard, but I find the variable length encoding very weird), I was rather talking of using WideString in UTF 16 or 32 and that's done. I saw asWideString but didn't know about automatic convertion or codepoint selector and internal wide string support. Does it means that Pharo Greek users (for example) use WideString for Strings without having to specify it or make explicit convertions (except of course when dealing with bytes if they want to) ? If yes, very good, job is almost done :) (personnally I would also deprecate ByteString, and get rid of it, just my opinion). Thanks for the link, another good chapter .

Regards,

Alain

Yes, the Greek users won't notice a difference, it is all transparent. ByteString is important because it is an optimalization of the most common case. As a normal user you should only think of abstract Strings and never use #asByteString (but use proper encoding). Feedback on the chapter is always welcome. Sven

On 25 Sep 2014, at 8:55 , Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 25/09/2014 07:23, Sven Van Caekenberghe a écrit :

...

On 25 Sep 2014, at 01:04, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :

...

Alain,

...

The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code.

You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing:

http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing.

Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before).

Sven

Very interesting ! It seems that most of what I was saying is already here :) I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a standard, but I find the variable length encoding very weird), I was rather talking of using WideString in UTF 16 or 32 and that's done. I saw asWideString but didn't know about automatic convertion or codepoint selector and internal wide string support. Does it means that Pharo Greek users (for example) use WideString for Strings without having to specify it or make explicit convertions (except of course when dealing with bytes if they want to) ? If yes, very good, job is almost done :) (personnally I would also deprecate ByteString, and get rid of it, just my opinion). Thanks for the link, another good chapter .

Regards,

Alain

ByteString is important because it is an optimalization of the most common case.

I understand the point here, memory/data footprint, cpu cache and so on (not talking of encoding/decoding). I think that's why Microsoft choosed UTF16 (old UCS2) as a middle solution because it covers most of character sets with 2 bytes.

It used to be a middle solution, back when UCS2 could encode the entire defined Unicode set. Novadays it's just the worst of both worlds; you waste memory for most normal text, *and* you don't have constant time indexed code point access. The duality we have in Pharo is an attempt to achieve the *best* of both worlds, wasting little memory for the "normal" case (latin1), and maintain constant time indexed access in all cases. The ultimate solution for this approach would have a trio of string classes with slot sizes 8 - 16 - 32 expanding / contracting as needed, but we don't have classes with variable short slots. (currently, they're planned in new Cog, if I've understood Eliots new object format correctly) Cheers, Henry

I'd love another title for this thread. It depresses me. Phil On Fri, Sep 26, 2014 at 8:48 PM, stepharo <stepharo@free.fr> wrote:

Sven I love this chapter. I will read it calmly now.

Stef

On 25/9/14 07:23, Sven Van Caekenberghe wrote:

...

On 25 Sep 2014, at 01:04, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 25/09/2014 00:06, Sven Van Caekenberghe a écrit :

...

...

Alain, The character encoding situation in Pharo is pretty good actually. The only problem is that there is some old school code left that encodes strings into strings, but today you can easily write much better and conceptually correct code.

You could have a look at this draft chapter of the upcoming 'Enterprise Pharo' book that I am currently writing:

http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

Concerning file system paths, FilePathEncoder and FilePluginPrimitives already do the right thing.

Now, your idea about using UTF-8 to represent internal Strings is something that has been discussed before and in many other languages as well. The short answer is that due to it being variable length, the inefficiency is (probably) just too high. Simple indexed access becomes a problem, let alone more complex string manipulations. I am not saying that it cannot be done, I think it is just not worth the trouble. The current solution in Pharo with ByteString and WideString is quite nice (check the chapter I mentioned before).

Sven

Very interesting ! It seems that most of what I was saying is already here :) I was not saying that Pharo should use utf8 (I mentionned utf8 because it is a standard, but I find the variable length encoding very weird), I was rather talking of using WideString in UTF 16 or 32 and that's done. I saw asWideString but didn't know about automatic convertion or codepoint selector and internal wide string support. Does it means that Pharo Greek users (for example) use WideString for Strings without having to specify it or make explicit convertions (except of course when dealing with bytes if they want to) ? If yes, very good, job is almost done :) (personnally I would also deprecate ByteString, and get rid of it, just my opinion). Thanks for the link, another good chapter .

Regards,

Alain

Yes, the Greek users won't notice a difference, it is all transparent. ByteString is important because it is an optimalization of the most common case. As a normal user you should only think of abstract Strings and never use #asByteString (but use proper encoding).

Feedback on the chapter is always welcome.

Sven

I'm not expert and I would like to know what people think. But I think that we should consider - the impact of spur new object format. I would like to have unicode and clean the leadChar Stef

Le 26/09/2014 23:22, Alain Rastoul a écrit :

Le 26/09/2014 20:47, stepharo a écrit :

...

I'm not expert and I would like to know what people think. But I think that we should consider

- the impact of spur new object format. I would like to have unicode and clean the leadChar

Stef

Just to start a new thread about that, because it deserves it and also some people might appreciate :) (was in: "Ridiculous we are").

I may not be the most qualified to state on that but I give my 2c (this is a community isn't it ? please do not flame...)

As Sven said, the situation is not so bad (quite good in fact): Pharo has true unicode built-in support with WideString and encoders (great job, IMHO this part of Zn components should be in the base system or in an internationalization package not hidden in an htpp components package). - encoding support has to be in the system : ZnEncoders(?) for utf8, unicode and other encoders for locale support because of existing system basis, web (utf8) and internationalization. - this will be transparent: Smalltalk is a typeless langage, one do not have to specify String type (ByteString or WideString) - Spur new character encoding is very interesting (in alpha stage now) and will be transparent for the same reason (though I'm still wondering of the 32bits/64 bits encoding on a 64 bits vm?). - ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code (again will be transparent to most users for same reason). - some parts of the system seems to be not "WideString/unicode aware" : Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but GT Inspector display is ok. Font plugin seems to require little work : uses fopen instead of _wfopen (utf16 version) on windows and needs utf8 convertion on unix. may be a check with File plugin (and other system related plugins) is also needed?

In short, some little additionnal work but a very good basis. (but what is leadChar about?)

Regards,

Alain

This was not a new thread indeed, I did "respond to group" I am ridiculous ... hahaha :)

Le 27/09/2014 01:02, Sven Van Caekenberghe a écrit :

On 26 Sep 2014, at 23:22, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but GT Inspector display is ok.

That is a font issue. Check your font settings in the Settings Browser.

Like I mentioned in the chapter, you could try to use 'Arial Unicode MS'.

I would guess you use Source Code Pro for code panes (like the workspace) and Open Sans for the rest. Source Code Pro has limited Unicode support. GT probably uses only Open Sans.

Ouch, forgot about different font settings for morphic elements, and evident, GTInspector could not display correctly if editor would not deal with WideString (forgot about bytestring/widestring transparency?). BTW I do not have Arial unicode MS on my system, it comes with MS Office, but Deja Vu and Bitmap Deja vu display some Greek chars correctly.

Le 27/09/2014 12:32, Sven Van Caekenberghe a écrit :

On 27 Sep 2014, at 05:51, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 27/09/2014 01:02, Sven Van Caekenberghe a écrit :

...

On 26 Sep 2014, at 23:22, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but GT Inspector display is ok.

That is a font issue. Check your font settings in the Settings Browser.

Like I mentioned in the chapter, you could try to use 'Arial Unicode MS'.

I would guess you use Source Code Pro for code panes (like the workspace) and Open Sans for the rest. Source Code Pro has limited Unicode support. GT probably uses only Open Sans.

Ouch, forgot about different font settings for morphic elements, and evident, GTInspector could not display correctly if editor would not deal with WideString (forgot about bytestring/widestring transparency?). BTW I do not have Arial unicode MS on my system, it comes with MS Office, but Deja Vu and Bitmap Deja vu display some Greek chars correctly.

It is a TrueType font, you have to enable it in System Setting, then you should see a very long list of fonts to choose from, not just one or two.

True type fonts are enabled on my system and I have a lot of fonts, but no Arial unicode MS. It doesn't hurt me not to have it, it's my personal laptop :) List of "products that supply this font" here: http://www.microsoft.com/typography/fonts/font.aspx?FMID=1081 Regards, Alain

Le 27/09/2014 13:40, phil@highoctane.be a écrit :

https://en.wikipedia.org/wiki/Open-source_Unicode_typefaces is also interesting.

Phil

Very interesting. And some nice fonts. I like Ubuntu and Roboto May be I'll code in Roboto for a while :)

On 29 Sep 2014, at 19:10, Robert Shiplett <grshiplett@gmail.com> wrote:

Must be a thing about European "guys" ...

<quote>

- ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code (again will be transparent to most users for same reason).

</unquote>

Of all reasons to retain ByteString, let's hope this one is not listed, lest we appear ridiculous in our threads.

Apart from being incorrect, it is indeed a totally wrong formulation which furthermore gives a bad impression. ByteString is simply an optimisation covering Strings where all characters use the lower 256 Unicode code points.

On 26 September 2014 18:22, Alain Rastoul <alf.mmm.cat@gmail.com> wrote: Le 26/09/2014 20:47, stepharo a écrit : I'm not expert and I would like to know what people think. But I think that we should consider

- the impact of spur new object format. I would like to have unicode and clean the leadChar

Stef

Just to start a new thread about that, because it deserves it and also some people might appreciate :) (was in: "Ridiculous we are").

I may not be the most qualified to state on that but I give my 2c (this is a community isn't it ? please do not flame...)

As Sven said, the situation is not so bad (quite good in fact): Pharo has true unicode built-in support with WideString and encoders (great job, IMHO this part of Zn components should be in the base system or in an internationalization package not hidden in an htpp components package). - encoding support has to be in the system : ZnEncoders(?) for utf8, unicode and other encoders for locale support because of existing system basis, web (utf8) and internationalization. - this will be transparent: Smalltalk is a typeless langage, one do not have to specify String type (ByteString or WideString) - Spur new character encoding is very interesting (in alpha stage now) and will be transparent for the same reason (though I'm still wondering of the 32bits/64 bits encoding on a 64 bits vm?). - ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code (again will be transparent to most users for same reason). - some parts of the system seems to be not "WideString/unicode aware" : Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but GT Inspector display is ok. Font plugin seems to require little work : uses fopen instead of _wfopen (utf16 version) on windows and needs utf8 convertion on unix. may be a check with File plugin (and other system related plugins) is also needed?

In short, some little additionnal work but a very good basis. (but what is leadChar about?)

Regards,

Alain

Le 24/09/2014 18:48, Benjamin Pollack a écrit :

On Tue, 23 Sep 2014 08:51:54 -0400, Hilaire <hilaire@drgeo.eu> wrote:

...

Le 23/09/2014 14:09, Damien Cassou a écrit :

...

I recently read documents about utf-8 encoding. In all of them, the author says that pathnames should be kept as is because you never know which encoding the filesystem uses. So, a filename should probably be a bytearray.

yes, but a #é should be encoded in two bytes.

As noted in my previous message, "é" could be represented as either one or two Unicode code points, and these in turn could validly be either two or three bytes in UTF-8. My gut says that $é should be U+00E9, because otherwise you should have to use two Characters ($e and $´), but you could legitimately argue otherwise as well, and at any rate, #é could definitely be either. This is likely the core of the issue you're hitting. As I understand it, #é should be encoded on two bytes and only two byte. Only ASCII is coded as 1 byte with UTF-8. See ref. on Wikipedia

Btw, I tracked the problem and provided a temporary fix. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu