TextPrinter Update

Correct, there's no reason to prefer the first over the second.

You can attach them here (just edit the opening post). Or you can send them by email, whichever you prefer :-)

Regarding the offset, try adding 0.375f or 0.5f to the vertex coordinates (not texture) - this should make the vertices align with the pixel grid (by default they align to the center of the pixels).

I suspect that this offset has something to do with the way the glyphs acquired. I didn't look at or change any of that code. I guess the glyphs maybe have some buffer around them? I don't entirely understand how the process of acquiring a glyph works at first glance.

OK, everything is working perfectly now. With the right StringFormat flags the glyphs are now being cached into the texture properly so they are drawn with the correct position and size when drawing a string. And after I took your advice about offsetting my rectangle by half a pixel, everything aligns perfectly. I've attached the updated code to the original post. Can this code be included in the OpenTK release?

After investigating these questions, I find, I think, there's a problem in MeasureString versus MeasureCharacterRanges that will require storing the offsets of the glyphs within their stored image buffers in order to properly position and measure the size of text. I'm in a rush at the moment, but will respond to the other questions when I can. (MeasureString does something MeasureCharacterRanges can't seem to do, and vice versa.)

OK, responses (in no particular order):

1) MeasureString seems to properly measure the entire width of a string while MeasureCharacterRanges will never seem to always get the entire width. I don't think I ever managed to get the two to agree in all cases even when using the same StringFormat objects. MeasureCharacterRanges seems designed for highlighting characters and doesn't care if bits of the characters hang out of the range, regardless of the StringFormat provided, if I recall my results. I guess MeasureCharacterRanges doesn't allow character regions to overlap, so if a character overlaps another character significantly, that overlap (or part of it) may be excluded from this character's boundaries, even though it can draw beyond those boundaries. And MeasureString is the only reliable way I've found to entirely measure a large italic lowercase "f" in Times New Roman. (And even that method cots off a column or two of pixels if you try to measure a 20-point italic lowercase "f" in MS Sans Serif, but that's not TrueType, so that might be an error by design).

2) I removed MeasureString because I thought GetCharacterRanges' functionality of returning the bounding rectangle in the layout parameter would suffice. After seeing how limited GetCharacterRanges is, I see that may not be the case. It's unfortunate that there doesn't seem to be a reliable way to actually measure the visible part of a glyph. I considered just taking the whole glyph rectangles and getting a union of them, but many glyphs have extra pixels around them, and depending on how much space the final measurement method leaves, using the glyph rectangles to measure a string might be less accurate then MeasureString.

3) GenericDefault leaves extra space around the characters, so that's why I thought I should use GenericTypographic. For a while it looked like I might have to use GenericDefault when measuring them and GenericTypographic when drawing them. But I don't remember how that worked out in the end. That might have eliminated the need to track offsets, but caused problems measuring the output size, probably. I was surprised when I found yesterday that there are apparently more differences between GenericDefault and GenericTypographic than any amount of property switching can "fix". I can't seem to find any way to change the properties of a clone of GenericTypographic to behave like GenericDefault, even if I change all the properties to match. Not that I need to convert one into the other. I just thought that a StringFormat object was entirely defined by its visible properties, and I guess it's not.

4) Depending on how drastically the new code needs to change to work correctly, it might make sense to postpone adding the Doc-Strings until they're settled down a bit.

5) I noticed the first character of each line appeared on the screen to be shifted by some fraction of a pixel because they appeared blurry (for a 20 point font). I wonder if this is related to AntiAlias setting. I wonder if MeasureCharacterRanges is offsetting characters by a fraction of a pixel due to a certain (visible or invisible) setting. This could be a problem if we get some glyphs being anti-aliased twice in the process of caching then drawing.

General text functionality is already in the utilities library. It no longer exists in the OpenTK DLL itself, as I understand it. Also, the existing functionality (with MeasureCharacterRanges) is "robust" for simple fonts. It only starts behaving oddly when you start using more complicated fonts (large fonts with kerning and italics). So it might be better to have a single font solution rather than multiple solutions. I think these problems will get worked out and then we'll have the best of both worlds: good font support for both simple and complicated/fancy text. The idea of providing a framework for a bitmapped font is interesting, though, because a good free font design tool is hard to find and use, and a lot of folks might prefer to just draw their font as a bunch of images. But I wouldn't see that as a core OpenTK component either. I think it's more important to get the commonly accepted font formats / text output to work well first, assuming it's do-able.

And have a robust builtin text font in the OpenTK.dll?
How would that look like though? With Serifs or without? We would probably end up with c&p 'Times New Roman' in a dozen possible sizes, and it won't be exactly the sizes people do want.
If Dogfight is locked to a single screen resolution, a simple bitmap solution might be your best choice since you can tweak it until it's just right. I'd recommend using TextPrinter tho and having some patience, there's still several construction sites at the core library and that obviously has higher priority than Fonts.
Please note that OpenTK is also open-source for the simple reason that people may contribute code, rather than making requests, wait and pray that it makes it into the next release.

Might even be a good-looking font, so as to improve the "OpenTK brand".
Don't take my (C), patent, or space-for-rent remarks too seriously, I'm just making fun of desperate capitalists and 'company warfare'. The .com in OpenTK.com should be understood as .community rather than commercial. I actually do prefer OpenTK.Net as it's more descriptive about the general idea.

Well if you look at it from that angle, OpenTK is made out of "OpenGL", "OpenAL", ".Net", "Mono" plus some convenience. I don't think it can exceed your personal perception of those brands, what OpenTK basically does is building a bridge between them to simplify cross-platform development using them.
I believe the projects built with OpenTK are more verbose what it is capable of (and thereby define the 'brand'), than any 'marketing deceptions' we could come up with.

I'm afraid I don't. Ubuntu, Suse, Red Hat & whatever are just Linux distributions to me, no preference for any of those. However if I had to chose one I'd pick Ubuntu since many people are talking positively about it, not because they have a pretty built-in font, shiny logo or whatever.

OpenTK moves away from branding as far as possible. It does not care if the box runs on "AMD" or "Intel" CPUs, "x86" or "x64", does not care what brand the graphics or sound card are - if it supports the necessary extensions - and doesn't care about the underlying operating system either.

I don't think it will help OpenTK in any way if we put 'a free Power-Ranger-Action figure in every box' ... err ... 'a free won't-suit-your-needs built-in font'. Our clientel are not 10 year old "will buy it when it's shiny" stereotypes, and like I said before the projects built ontop of OpenTK will speak a much stronger language about it.

The only "brand" that could be considered a direct competitor to OpenTK is the Tao Framework, but I actually do encourage people to look into it for functionality that is missing in OpenTK, because Tao has a wider scope of included libraries.

Probably more like:

"Have you tried OpenTK?"
"Yeah, it's a great OpenGL API for C#. They got some simple built-in font noone uses - I feel bad for the guy who wasted days of his life tweaking that thing - because their Font class allows chosing any .ttf font at any size you want.
There's also this awesome Fluid simulation demo in the projects section. It's quite fun to play around with that, you should take a look."

Seriously, why add a default font, but not a default Texture, default Soundfile, etc.? Those are artist products, they don't even give the slightest hint about the programmer's API.

Objarni, I think you are blowing the issue way out of proportion:

1. The artifacts only affect specific intel chips/drivers.
2. The lack of grid-fitting causes glyphs to appear blurred on Windows (not Linux), but this is not world shattering. Besides, a bitmap font such as the one you suggest would suffer from the very same issues.

If you really find these issues disturbing, implementing and debugging a simple bitmap font-renderer won't take more than a day. You can then package it into a dll so that other people can benefit (I'll gladly host the code if you wish).

Also, despite what it looks like, this issue isn't dead and buried - I'm actively testing native solutions like Uniscribe/Pango/Atsui (the ones mozilla/gecko is based on). I'm not saying these are suitable for OpenTK (imagine 2-3 KLOC for each one, not counting the p/invokes), I'm just indicating that fonts are a topic without easy solutions.

I think I've found a solution - expect an update soon.

Ahem, this is already implemented. Take a look at this thread.