Response title
This is preview!
This is a continuation of recent discussion, wherein Andrew mentioned his design ideas for a TextEngine. The gyst of it to me is that could use a more extendable glyph manager, which is quite apparent by looking at the number of #defines in the TextureFont implementation. The problem is that every platform handles glyphs differently, and none of it is pretty. I'll repeat his description before going on:
Currently my thought is that we should design a TextEngine class which implements acquiring glyphs, placing glyphs, measuring strings, instantiating Fonts, etc. So we'd have a TextEngineCoreText, TextEngineFreeType, TextEngineDirectWrite, etc. This means that Fonts are a "child" of a particular TextEngine as well. For convenience I'm inclined toward creating a singleton that is the default TextEngine which you get when you don't specify one. So you can easily enable say, FreeType globally from your app's setup and then not worry about it anymore. But if you had some particular need to do so, you could provide an instance of TextEngine to the Font constructor or something along those lines.
The important design features I get out of this are:
I've been looking at the TextureFont implementation for Cocoa quite a bit over the last couple weeks, so I figure I can plunge in and prototype this in a CinderBlock for OS X. But first, some questions:
Baseline issue: there's a difference in the way drawStringWrapped is implemented with Cocoa vs Freetype that needs fixing, see TextureFont::drawStringWrapped.
Not sure if it makes sense to keep the Font::getDefault() and Font::getNames() methods around, but replacing them requires a bit of thought because of how they're called.
Any Texture atlas implementation requires some concept of a subrect of another Texture
The Font::getDefault() method is convenient for classes that want to initiliaze there FontRef ivars without needed to know about TextEngine (it's used this way in a few different places). But maybe it should take an optional TextEngineRef parameter.
To handle DataSource identifiers requires extending FontType, defining FontType as a [ URL | filepath | hint | name, path, (float) size ]