Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upRefused to open font files with non-ascii names - Cannot marshal: Encountered unmappable character. at SharpFont.FT.FT_New_Face(IntPtr library, String filepathname, Int32 face_index, IntPtr& aface) #89
Comments
|
Argh, this is a more difficult issue than I thought. Mono apparently treats CharSet.Ansi as utf8, which is why I never saw it until now. I am seeing it because I am running SharpFont under wine with the genuine MS dotnet runtime at the moment (it is just a special thing that I need to do now, instead of using native mono). The behavior with CharSet.Ansi is as documented but undesirable - freetype itself on windows can open font files with non-ascii file name or font names, just treat them as null terminated c strings. Using CharSet.Ansi is uncessarily restrictive, but CharSet.Unicode probably won't work on windows, since freetype does not really expect arguments to come in as UTF16LE's (I assume that's what is meant by marshalling as "CharSet.Unicode"). |
|
Yikes, this looks like a pretty complex one. I suppose we could try to manually encode UTF-8 and have the extern functions take IntPtrs instead. Does FreeType expect UTF-8 for those APIs on all platforms? |
|
Freetype treats the input as raw bytes, does not really apply any encoding to it - as long as it is null-terminated c byte arrays. I can't see a quick way fixing this. One possibility is you open the file in c# and pass the file content as a memory block. |
|
There are already Face constructors that do this for
I can also add an extra overload that takes some type of stream ( Another thing we can do is adapt a C# stream to FTStream so that it's easy to call Library.OpenFace. |
|
I guess what I like, is for |
|
Back-ported streaming support Running on English name was successful, I have not tried non-ascii name yet. |
|
I'll be testing the backport soon, so assuming that's successful, this can be closed. |
….0 build
net4 build of SharpFont, 4.0.1+fixes from HinTak/SharpFont:v3.0.1-75-ge1b444c
cd Source/SharpFont && xbuild SharpFont.csproj
git@github.com:HinTak/SharpFont.git v4.0.1+fixes v3.0.1-80-g670aa0b
cd Source/SharpFont && xbuild /p:TargetFrameworkVersion=v2.0 /property:Configuration=Release SharpFont.csproj
4.1.0+fixes need to do without dll
upstream addition 8efddb79a3d55bca01e5e80e8f3782e8f8c5fbab
xbuild /p:TargetFrameworkVersion=v2.0 /property:Configuration=Release SharpFont.csproj ; v3.0.1-81-gc574260
Part of the fixes to
microsoft#49
Robmaister/SharpFont#89
and is built for dotnet2:
microsoft#42
See also:
Robmaister/SharpFont#95
and also
Robmaister/SharpFont#82
|
The streaming support seems to lose the file handle once in a while - like one test out of 50... needs better looking at. |
There is no need to restrict to ascii file names?
I see it is set in the DllImport marshalling to
Here is the list of routines with the above set:
PropertyGet/Set never have non-ascii arguments, but file names and font names do!