Why would you be surprised by that? Do you know how hard full-fledged Unicode text layout is? I know of exactly two open-source libraries that can do Unicode text layout: ICU and Pango. Both of these libraries are designed to care as little as possible about how you actually render the glyphs.

Drawing some glyphs with OpenGL is easy. Drawing the right glyphs in the right place with any graphics API is the tricky part.

Well I will accept that as an answer. It's not something I've looked into, but for the record this is built into Windows. Look into DrawText. The easiest thing to do might be to render the text with Direct3D to either an overlay window or to a neutral device context with a dynamic texture if your text is the usual sort of thing you find in a video game.

That reminds me though that you can also use DrawText (or a related API; as I recall) in a way that does not actually display text, and then query the text that it would have drawn, so that effectively you end up with the Unicode layouts that you would find in the likes of Internet Explorer. You would just need to capture and render the glyphs somehow.

EDITED: I think that might be what you are supposed to do with wglUseFontOutlines and wglUseFontBitmaps (depending on the kind of font you have etc) but these are documented to rely on display lists, and I don't know how good those are anymore. I think the concept should be added to WebGL (due to the runtime limitations of JavaScript) but otherwise that is probably not the right way. It might be a good step for generating a font texture by whatever terms OpenGL uses for render target textures

EDITED: It's too bad those APIs do not expose the texture that the display lists would have used because that might save you the trouble of drawing the display lists to a render target.

Last edited by michagl; 09-25-2012 at 09:05 PM.

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

That wouldn't be an open-source library. That would be a specification that someone has to implement. Just like virtually everything else Khronos does. There's no point in providing a specification for a library like that.

That wouldn't be an open-source library. That would be a specification that someone has to implement. Just like virtually everything else Khronos does. There's no point in providing a specification for a library like that.

While I was jesting. I dunno. Pango seems top heavy and doesn't feel like an open standard. ICU (thanks for the heads up) looks like something that should be under the hood so to speak. Fonts are central to graphics, and doing fonts without Unicode is almost pointless to go back to. At the same time Unicode is a lot to deal with. So having something potentially as widespread as OpenGL for Unicode would be pretty important. I think it would probably make more sense for something like GLUT or GLUT itself to implement. Windows has DrawText, so it really has a leg up on everyone else if something as simple to just use cannot be figured out by everyone else.

I mean if there is already wglUseFontOutlines which presumably can do any kind of font for Windows. Why not just modernize it. X has glXUseXFont apparently. These can render any font. They just need a portable layout framework to match them now that we are in the Unicode age.

PS: Literally DrawText is just like pick a font, any font, and give us a string to draw. It's that simple. You just have to deal with cobbling together your own hybrid fonts to make sure the glyphs you need are in the fonts you are drawing.

Last edited by michagl; 09-25-2012 at 10:01 PM.

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

"Modernize it" into what? Into GLUT? Well, GLUT is defunct, so that would have to be FreeGLUT. And while it is active, I'm pretty sure they're not going to build a full Unicode text layout system into their application.

You want a lot of things, but they're not going to happen. Or more to the point, if you want them to happen, you are going to have to make them happen. If you want this in FreeGLUT, then put it into FreeGLUT; it's open source.

Yeah that is the expectation. Meanwhile apparently non-Windows platforms do not have reasonable text rendering options for people like the OP. Not knowing what Apple has for their Macs.

That mentality just leads to confusion and imperialistic programming patterns which is not good for anyone.

Fortunately the OP seems to be working exclusively with Windows. So he/she has many options laid out before them here now.

If they were looking to be cross platform then they (apparently) have nothing.

PS: Everywhere I see OpenGL I see GLUT. So apparently it's still popular. I am working from the assumption that GLUT is basically the D3DX of OpenGL, but I am pretty willfully ignorant about these things. If not GLUT then it should be built directly into the OS (environment/window manager) side of things. If the OS doesn't have said features then it's already behind the ball. Disclaimer: I am not familiar with the status of Unicode fonts with X/Linux or OSX but X has font facilities so it should be able to do its own layouts without every application having a dependency on something like Pango and there is no reason why OpenGL could not or should not facilitate that.

Last edited by michagl; 09-25-2012 at 10:45 PM.

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

Modernize it to not using de facto deprecated features the likes of display lists. Though I don't know if display lists are really such a sin for rendering a moderate amount of text. They are obviously not part of OpenGL ES; which should be able to render fonts out of the box too. For a full screen in a text editor it sounds like an awful idea (but at that point you might be able to justify using something more like Pango)

It's just not unreasonable for a graphics API to be able to render fonts properly one way or another. Even the more so if we are to really embrace Unicode (open multi-culturalism) sooner or later.

Last edited by michagl; 09-25-2012 at 10:58 PM.

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

If they were looking to be cross platform then they (apparently) have nothing.

Pango. ICU. Cross-platform.

Are we even having the same discussion here? Just because it's not in OpenGL itself doesn't mean it doesn't exist.

Disclaimer: I am not familiar with the status of Unicode fonts with X/Linux or OSX but X has font facilities so it should be able to do its own layouts without every application having a dependency on something like Pango

You're used to the Windows world, where if "the system" doesn't do something, then it may as well not exist. That's not how things happen outside of the Windows world. In the not-Windows world, you use libraries to get things done.

If you use GTK, you have a dependency on Pango because GTK uses Pango for its text layout. It uses LibXML2 for its XML reading, so you have another dependency there. And so on. That's how things work in the not-Windows world: you pick your libraries and use them. Some of these are provided by the system. Some of these are provided by you.

Functionally, there's no difference between having a dependency on Pango and having a dependency on Uniscribe. The only practical difference is that in the Pango case, you have to link to the library explicitly, while in the Uniscribe case, you don't.

It's just not unreasonable for a graphics API to be able to render fonts properly one way or another.

It is very unreasonable.

OpenGL is supposed to be a relatively thin wrapper around graphics hardware, in order to achieve a reasonable abstraction and allow for a reasonable platform-neutral interface to that hardware. OpenGL's job is not to make it easy to do complex things. It's job is to make it possible to do complex things. If something can be layered on top of OpenGL, then it should be.

You won't find any font rendering functions in D3D either, for similar reasons.

I am not working exclusively with Windows, actually. The use of GDI+ (a painful experience as it were) is just temporary.

So how would you gentlemen advise me to continue?
The fonts themselves are drawn with GDI+, but I have no glyph metrics whatsoever - the fontmap generates crude metrics as it goes.

First it takes the default position of the symbol 'Á', and takes note of its height and Y coordinate in a bitmap so it can position smaller and larger characters on the same 'line'.
It's crude, but it actually works. They are positioned in the fontmap's texture with their whitespace intact and therefore it's just a matter of picking out the correct rectangle to draw.
Proud though I may be of this thing actually working, and since my work on the textbox is mostly done (thanks, Alfonse), I now seek an alternative to GDI+ - a cross-platform one if possible.

I've seen the names ICU and Pango floating around, so in the meantime I'll go check what the buzz is all about.

Also, this is how the font looks in the textbox - my eyes hurt from looking at it.

It works as a drop in replacement for wglfontbitmaps. Proper anti-aliased fonts for win32. Opengl 1-2 support.
It's not especially fast because it uses gldrawpixels, which doesn't seem to be very fast. But it works fine nonetheless.