On 22 Sep 2014, at 10:07 , Hilaire <hila...@drgeo.eu> wrote: > > 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.
The fun thing about plugins calling external libraries, is that you have to find out what that library does to know the right answer to what encoding char* parameters are meant to be passed... In the case of FreeType, after some digging*, it seems to me it ends up calling fopen on all platforms, which on windows... *drumroll* ... resolves to the legacy ANSI version** of the Windows file libraries. Hence, the "correct" encoding to use on Windows would be the locale legacy code page. It also means that, on Windows, you *cannot* load fonts from a directory whose name is not encodable in the current codepage no matter what we do in Pharo. (short of submitting a bug-fix to the FreeType project) Cheers, Henry *FT_New_Face (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftobjs.c) calls... FT_Open_Face (same) which calls... FT_Stream_New (same) which calls... FT_Stream_Open (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftsystem.c) which calls... ft_fopen (http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/config/ftstdlib.h) which resolves to f_open. ** http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx , don't be fooled, the "Unicode support" section is about contents written/read to/from file, not the path parameter.
signature.asc
Description: Message signed with OpenPGP using GPGMail
