Can the instructions for how to use this please be updated?

[tbandtg]

I have been struggling with this for days. I finally was able to get the spacewizards version to work with a .netcore app for windows after I downloaded someone elses freetype6.dll. But then when I zipped that up and tried it on another computer and bam it complains about the freetype6.dll.

I have downloaded and built freetype, does it still need the patch ran? I mean it now has an x64 build option does that take care of it? Anyway even after building freetype it didnt work.

If there is a way to get started quickly from the nuget package and have everything working, that would be great. I dont need deep functionality just the ability to open a ttl file and extract glyph info to create a bmp.

[HinTak]

I don't know anything about nuget, but you can
download the whole of the Win32 or Win64 folder at https://github.com/HinTak/Font-Validator/tree/master/bin . (the other dlls are what freetype6 depends on), or the win* releases and just grab those folders.

The win64 patch is always needed. It is for incompatibility between c# and c, really.

[tbandtg]

I downloaded that whole project and grabbed those folders, and it worked fine on my machine but when I deployed it to another machine it failed to load freetype6 dlls.

I ensured that the entire dll directory was there.

[HinTak]

Do you know if you are using a 32-bit or a 64-bit dotnet runtime? The c# part does not care, but when it calls back to c code as in this care, you need to use the matching one. Maybe your machine and the other machine differs this way.

[HinTak]

I have both and have some auto dispatch code to find the right one : https://github.com/HinTak/Font-Validator/blob/435ec1e2b49bba82231442bdebf63bcad28c70b1/Compat/Compat.cs#L72

[tbandtg]

I have tried both, by changing the project between x86 and x64. I will use your code to try to get it to chose between the two libraries.
All I needed was a library that could open a ttf file and give me glyph metrics at a certain em_size + a bmp of ibpp glyphs.

This works great on my machine, but doesnt work at all on any other machines. I dont normally develop in windows or C# I thought this would be a simple beyond simple project to do. And it has turned into a big headache.

I have bounced around between Glyphtypeface class and sharpfont and glyphrun .... I mean I am not trying to make rocket fuel here.

The amount of code required is far surpassed by the absolute not working of any libraries. I find it hard to believe that there are no native libraries provided by microsoft for .net to load a ttf file and parse out a glyph.

Output that is supposed to happen.

Output that happens on anything other than build machine.

If there is a tutorial somewhere that actually works that would be super awesome.

[Robmaister]

I really haven't had any time to maintain this project over the last few years so I'm not really sure where it stands with the modern C# ecosystem. At a glance it looks like that should be working, I see that you already have Dependency Walker, did you see any issues related to a missing CRT dll dependency on freetype6.dll?

Most likely scenario is that one machine had the right VC++ redistributable installed and the other didn't. I tried to build the dll for a bunch of different CRT versions but that requires a lot of maintenance.

[HinTak]

That screenshot tells a different story - the presence of libgcc_s* means it is gcc compiled (and possibly cross compiled), and the presence of libharfbuzz is worrying: harfbuzz is a large c++ library (as opposite to c), and brings in a hell lot of other dependencies like libglib* and stuff. Gcc compiled freetype does not depend on msvc runtime but on libgcc_s* (you need the matching one - it is different for win32 vs win64)

The above screenshot is missing zlib1.dll . It is very common (and bundled by many software) but could be missing on your depol machine.

I spent a lot of time making the minimum (and without harfbuzz!) number of dlls.

Gcc compiled / cross-compiled follows Unix build instructions.

[tbandtg]

I am recopying everything and will update. I am also going to add your if statement for dll based off of which version of windows.

[HinTak]

@tbandtg at the moment most likely you are missing zlib1.dll on your depol machine, especially if your depol machine is new/clean and your dev machine older and much used.

zlib1.dll is quite commonly bundled by many other software and some of them copies it to system32 and make it available to other software. As you see fontval bundles it too, but keeps it local. Your screenshot does not show it.

[tbandtg]

This all actually worked, thanks allot.

The only thing I noticed is that it renders some glyphs slightly differently depending on if using sharp font or a program that was developed a long time ago using free type.

I do not know if the rendering algorithm has changed, as of right now I am not worried about it but I do find it curious. Notice the third line.

[HinTak]

Are you talking about same backend invoked via SharpFont vs something else, or just two different runs on different platforms/versions? Especially at the lower resolution, 1-pixel changes like that shown is quite common - maybe not for changing compiler options, but you know, it happens when a number is just above 0.5 done in one way, and below 0.5 in a different way.

The actual rendering, especially for Arial (a Microsoft font, known to be heavily hand-hinted) the hinting algorithm has changed a bit between 2.6 and 2.7, and also somewhat recently too (2.10?).

[tbandtg]

Different runs on different versions. thanks for clearing it up. As I said it hadnt been a show stopper. It is clearly just a bit different.

[HinTak]

I shouldn't write "common"; "not unheard of" is more like it. At low resolution, when the curves are grid-fitted etc, part of it can cross-over the centre of a pixel, between version/platform/different rounding from compiler, and turn it from "on" to "off" or vice versa. Anyway, both look acceptable and neither is obviously wrong, where the edge of the Q curves around.

[tilkinsc]

I forced x64

<PlatformTarget>x64</PlatformTarget>

and then just ended up putting the dll I needed into bin/**/runtimes

This project needs to be published with the libraries in the correct RID folder structure so that it pulls correctly. I do this in https://github.com/tilkinsc/Lua.NET if anyone wants to tackle this.