-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refused 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. |
….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
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!
The text was updated successfully, but these errors were encountered: