Implement Library.PropertySet on int type. #84
Conversation
Specifically, this is for making
_lib.PropertySet("truetype", "interpreter-version", 35);
_lib.PropertySet("truetype", "interpreter-version", 40);
work.
Robmaister#82
|
I believe there's a better way to get this working as a generic function. Have you tried pinning value with a GCHandle? |
|
I haven't... If you can get the generic/template function PropertySet<T> to work for value types that would be great :-). Tried PropertySet<int> and a few other things... PropertyGet does not work either, but I can live with just blindly setting it and trust that the value get set :-). |
…arameter. I believe the original code [1] for PropertyGet with a "out IntPtr" last argument is wrong for value types like int. Whereas pointer types get the IntPtr filled in with by having the pointer to a pre-existing structure within Freetype, when FT_property_get() is called with &int as a final argument, the caller is expected to provide the storage which the pointer is pointed to. Hence "out IntPtr" will never work when FT_Property_Get expects int* , as the storage pointed to by the pointer never existed. This enhancement fixes: Robmaister#82 (I tested this - it works for my purpose - doing: int b; _lib.PropertyGet("truetype", "interpreter-version", ref b); // b is 35 _lib.PropertySet("truetype", "interpreter-version", 40); _lib.PropertyGet("truetype", "interpreter-version", ref b); // b is now 40 ) Also note that [1] said "untested" - do not know if it is still true: [1] commit 0ad176f Author: Robert Rouhani <[email protected]> Date: Fri Jan 25 21:46:15 2013 -0500 Updated to FreeType 2.4.11, untested.
|
I think the "out IntPtr" part of PropertyGet is wrong - it might have worked without the "out" part, but it certainly won't work for &int , as "out ..." discards the input pointer and expect the routine to give the pointer a value. "out intPtr" is correct for reference types, returning a pre-existing pointer to a structure within freetype, but wrong for &int, where the routine expects a valid input pointer to a valid storage of 4 bytes to fill. In any case, my addition works for me. |
…16 xy, Fixed16Dot16 yx, Fixed16Dot16 yy)" signature Robmaister#87
The three patches are as in: Robmaister/SharpFont#84 v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-21-ged9e820 v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-22-g397f5de v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-23-g04b26af
The bulk of this diff depends on enhancements submitted for FreeType ( the "diagnostics patch" ) and three enhancements to SharpFont ( Robmaister/SharpFont#84 ). Most of the rest is some by-pass code that talks to FreeType directly without going through SharpFont; this should eventually ends up in SharpFont. As such, essentially the whole of this diff would be rewritten and revised, and should not be depended on. cp -p bin/SharpFont.dll.config bin/Compat.dll.config; in preparation of DllImport
This fixes the problem, where passing by value does not update the source object: Robmaister#88
…rary.SetProperty and Library.GetProperty in the process
|
As mentioned in the issue, all overloads are now tested working. |
|
I'll assume at this point that my generic implementation works just fine for you |
|
I assume so - however for even starting the testing, testing under dotnet2 runtime is a necessity. So I cannot look at SharpFont 4.0 until it regain dotnet2 runtime support. I might have to do it myself, or just keep using a forked 3.0 - the latter is easier, unfortunately. |
|
Can you not just apply a LinqBridge reference/copy System.Core.dll in as discussed in #95 a while back? Everything up to .NET 3.5 will run on a 2.0 CLR given the correct libraries. I would be a whole lot more understanding if we were using something like async/await that was wholly incompatible with the 2.0 CLR, but LINQ is just a library with some syntax sugar with simple backwards compatibility solutions. I view this in a similar way to how I provide builds of freetype6.dll. The last builds I did of freetype6.dll supported down to MSVC8 only because I managed to install VS 2005 on Windows 7. If it doesn't work in Windows 10 when I get around to setting up the same environment on my new machine, then I won't build them for versions that old. (In the same way I don't build against MSVC 7.1, 7, or 6). There are still instructions in the repo/elsewhere online on how to compile the library if you'd like to spin up an XP VM and compile against ancient VC++ runtimes. |
|
Whichever way of moving up to 4.x - backpacking to dotnet2 or grafting a 3rd party 3.5 on top - is extra work; and I am okay with a forked 3.X at the moment. Actually the reason I must support dotnet2 is this: So one way for me not to need dotnet2 is if that wine-mono bug gets fixed. |
…all overloads of Library.SetProperty and Library.GetProperty in the process Conflicts: Source/SharpFont/FTStream.cs
…all overloads of Library.SetProperty and Library.GetProperty in the process
The three patches are as in: Robmaister/SharpFont#84 v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-21-ged9e820 v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-22-g397f5de v3.1.0+fixes: xbuild SharpFont.csproj HinTak/SharpFont:v3.0.1-23-g04b26af
Specifically, this is for making
_lib.PropertySet("truetype", "interpreter-version", 35);
_lib.PropertySet("truetype", "interpreter-version", 40);
work.
#82