^So is it safe to assume that all of the code above is your own (wrapped around the public libraries we are negotiating) ?

FYI: It should not be necessary to use "simulated glyph metrics" with the GDI based fonts. I remember DrawText will ignore leading and trailing spaces in lines of text so I had to manually calculate the metrics to get correct results. With Unicode there are more than a few kinds of spacing characters, and I did have trouble making sense of the metrics, but eventually I figured them out. They are confusing maybe, but surely they are the same metrics Windows uses under the hood. You just have to spend more time with them I suspect.

Also it's disappointing if Pango requires fonts to be installed. I find it's very helpful to go around the installed fonts with games. The software I have been working with for a while now originated in Japan, and to make it work as intended it's easiest to just deliver the core fonts with it since many people do not have Windows' Japanese fonts installed (Unicode fonts don't really count) plus game authors and translators like to use custom fonts and asking the end user to install fonts for a game on demand is really bothersome, plus the font will remain installed after the game is no more.

PS: I suspect the best approach here would be to use GDI as much as possible on Windows. And do whatever is necessary on Linux with X... possibly going low-level if need be. If Pango will only do installed fonts on Windows it's not going to give you anything (critical) that GDI can't do, so it's probably not worth the dependency in my book. Probably implementing something like ID3DXFont that works with OpenGL (basically what you were originally doing) is a good way to go if the fonts must be displayed with OpenGL.

Last edited by michagl; 10-16-2012 at 11:45 AM.

God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.

Usage of installed fonts is not Pango's limitation, but merely my own. I don't care for portable fonts enough to bother with converting the .NET Font object to the Pango Font object. And yes, all the code is mine.

Also, I tried quite a bit of GDI+ measuring functions, but it always returned padding and other stuff that makes it (to me) impossible to get the exact size of the glyph. In the end, I have simply settled for a loop that maps the area the glyph is occupying. Although that was also one of the slowdowns I got with the GDI+ version. No such thing is necessary with Pango.

^So is the above code is reading back the pixels as a way of determining the bounds of the glyphs? Sorry I am just scanning the code.

The metrics provided by GDI are first and foremost for the letter spacing, so that includes padding naturally. Plus there is kerning too if you want things to look really nice. I don't have great memory, but if you wanted like the width between the leftmost and rightmost (or vice versa) non-empty pixel then yeah, that's a little bit unusual. I'd not be surprised if those metrics are available but I would not be surprised if they are not either.

If you include the padding in your textures it would probably remain sufficiently packed together. Sometimes things that seem like savings are really not even worth the time to worry about.

PS: Does Pango not honor all fonts installed by Windows?

God have mercy on the soul that wanted hard decimal points and pure ctor conversion in GLSL.

Yes, the code scans the buffer bitmap (the size of which is determined by a rough metrics returned by GDI+) pixel by pixel and determines its bounds. It's primitive and it certainly could be improved, but for GDI+ it worked good enough.

And I guess there is a way to get some meaningful numbers, but GDI+ is not worth the time - Pango is much nicer to work with _and_ it's not Microsoft-exclusive.

I don't understand what you mean by "honoring" all fonts. Pango sees all the fonts that are installed and uses them without any problem.