SharpFont.HarfBuzz should use the latest (Portable) version of SharpFont

[corliss]

Just checking in to see whether the discussion in #7 is still alive. I am finally concentrating solely on using SharpFont and SharpFont.HarfBuzz. This issue is to help reboot the threads of the other discussion.

Since SharpFont has already taken a step in the right direction, some suggestions:

1. SharpFont.HarfBuzz currently depends on the old version of the SharpFont code, so it would be great to have it running against the new code.

2. There are currently three projects - SharpFont, SharpFont.Portable, and SharpFont.iOS. The only difference between SharpFont.Portable and SharpFont is the bitmap code in FTBitmap.cs, so maybe just that code can be abstracted into a separate library named SharpFont.System.Drawing or some such?

Additionally, perhaps SharpFont.iOS could be removed? The currently #ifdef'd out APIs could just throw an exception at runtime if they are called on the wrong OS. It seems the #if's should be checking for macOS rather than iOS, i.e.:
#if macOS
rather than
#if !iOS

To do this without conditionally compiled code requires a way to determine the OS from the portable class library, which is possible in this specific case. I'll prepare a pull request for this.

tl;dr: Replace all three dll's with a single portable library, and move the platform-specific bitmap code to a different assembly (or just publish it as a source file to be included directly.

3. Is the 64-bit patch to freetype really required? I ask because it would be ideal to not have to worry about producing custom builds of the native binaries. On the other hand, if native builds are needed for other reasons, then this doesn't matter as much.

4. It would be great if there were a self-contained version of SharpFont.HarfBuzz that included all the dependencies, including C# FreeType wrappers and the native libraries, i.e. everything that is currently in SharpFont. Is this feasible?

5. Any traction on getting rid of the glib dependency that was mentioned in What platforms are supported (or will be supported)? #7?

Cheers,

[Robmaister]

Sorry, I've still been really busy w/ other things - not sure when I can devote time to actual development.

1. Will naturally happen next time I have a few hours to devote to my open source stuff.
2. I specifically added that code to help lower the barrier to entry and make it easier to shuttle rendered glyphs to other libraries that accept Bitmaps. From what I've seen, this function does get a lot of use currently - so if possible, finding some way to keep it on platforms that have System.Drawing would be ideal...

The current PCL setup including iOS/desktop/PCL was contributed in one go, and I'm not super familiar with PCL and the recommended patterns for handling platform-specific code, so I'll gladly accept a PR for this!

3. Yep. The solution before was to use the preprocessor to build separate versions of SharpFont for Windows. FreeType makes heavy use of the native long type. On Windows, this is always 4 bytes. On every other platform, it's 4 bytes on x86 and 8 bytes on x64. C# has no integral type that behaves this way. The patch forces __int64 on Windows x64 on the native side instead, so that we can use the C# IntPtr and UIntPtr types.

Windows doesn't really have package management, the GnuWin32 builds are nearly a decade out of date and have no 64-bit builds. The only problem we would possibly run into is someone using our dll and their own lib + headers in a 64-bit C/C++ program, which would be strange to say the least.

4. Possibly, we would have to find a way to pack the native dlls in and select the right one based on host x86/x64 bitness. We would still need multiple builds based on the version of the VC++ runtime that freetype6.dll was built with (unless we can strip it out, which is possible, but I'm unsure of the side effects). I haven't seen anyone else do this, would be pretty cool if we could get it working

5. Not yet but seems like it's just rebuilding harfbuzz with some flags turned off?

I'll see if I have any time this week to at least touch on a few of these points, at the very least 5.