How to use as a library?

[smolck]

Title says it all; I'd like to use this as a library, but I'm not quite sure how to go about doing that. This feels like more of a C++ question than one related to this library (my knowledge of building C++ code is extremely limited), but I'm not sure how building everything together would work for this library specifically so figure I might as well ask here. A minimal example usage would be extremely helpful, but even just some pointers for where to look to learn what I need to get up-and-running would be appreciated.

[Chlumsky]

My goal was to make the library portion as flexible as possible so that it can be used in many different ways, such as - the way it's used in the standalone executable, to progressively generate requested characters on the fly in the background, to work in a GPU accelerated context or not, etc. Because of that, it is nowhere as simple as generateEverything("myfont.ttf"); and done. What use case do you have in mind?

I can try to describe what roughly happens in the main.cpp, starting about here. Keep in mind there is a lot of extra code because of all the different settings and error reporting.

1. Acquire font handle (msdfgen::FontHandle *) using msdfgen::loadFont (after initializing msdfgen::FreetypeHandle *).
2. Load the desired glyphs into a FontGeometry object, e.g. using FontGeometry::loadCharset.
3. Lay out the glyphs into the atlas using TightAtlasPacker - set known parameters such as dimensions, scale, or range and then pack.
4. Compute edge coloring for each glyph (GlyphGeometry::edgeColoring) if generating a MSDF.
5. Create an ImmediateAtlasGenerator with the appropriate template arguments and image dimensions and set its attributes.
6. Generate the atlas bitmap using ImmediateAtlasGenerator::generate.
7. Done. The bitmap is now available via ImmediateAtlasGenerator::atlasStorage and the positioning data are stored in the glyphs in FontGeometry.

[smolck]

My goal was to make the library portion as flexible as possible so that it can be used in many different ways, such as - the way it's used in the standalone executable, to progressively generate requested characters on the fly in the background, to work in a GPU accelerated context or not, etc. Because of that, it is nowhere as simple as generateEverything("myfont.ttf"); and done. What use case do you have in mind?

Yes, that makes sense; my current idea is to improve the text rendering for a text editor I work on, uivonim, using MSDFs generated by this library. Since it's an electron-based editor, I'll need to first create a native node module that binds to this library so I can use it, and that's where I ran into issues with it being usable.

Some of the functions did indeed work (using this nan quickstart as a start and this library as a submodule), but it required adding many if not all of the the source files to the binding.gyp file, and even then I would get errors about freetype symbols not being defined. I tried linking to freetype since that was almost certainly the problem, but to no avail.

Perhaps that's just due to my poor understanding about building C++ libraries, and specifically in the context of a native node module (haven't ever built one before so this would/will be a learning experience, and was), in which case that's fine; but if I had an easy way of building this library into a single shared library or something, that would be wonderful. My ideal would be being able to do something like this, I guess:

// main.cpp
#include "msdf-atlas-gen/msdf-atlas-gen.h"

int main() {
    // do stuff with msdf-atlas-gen
}

and then perhaps build it via g++ main.cpp -L . -lmsdfatlasgen or something. Or perhaps a CMakeLists.txt could be provided that handles dealing with the deps (msdfgen in particular) and building everything, so it could be easily used in a new project? Again, my familiarity with the C++ ecosystem and how to use it is not very good, so you very well might know a much better way than this.

I can try to describe what roughly happens in the main.cpp, starting about here. Keep in mind there is a lot of extra code because of all the different settings and error reporting.
[...]

Thank you very much for the explanation! I was able to pick up some of that myself reading through the source when trying to get that native node module working, but definitely not all of that.

[Chlumsky]

You should be able to easily modify the makefile to do this by removing the standalone macro and adding your own main file. Or change it to build as a library and then link it as well as FreeType, I don't see what the problem is.

[smolck]

You should be able to easily modify the makefile to do this by removing the standalone macro and adding your own main file. Or change it to build as a library and then link it as well as FreeType, I don't see what the problem is.

The problem was/is my lack of understanding on how to do the latter; I had apparently missed #8 though, the CMakeLists.txt of which, after a modification or two, seems to work fine and should work fine for my usecase.

Thanks for the help, and my apologies for the dumb question!