JTalton's picture

Fonts - Yet again

Windows XP
I converted my application over from using TAO.SDL and the SDL TTF library for rendering fonts to using the OpenTK fonts.
The OpenTK fonts don't have the correct pixel precision and the look blurry. Also the bottom of the font is getting cut off.
Am I missing a setting? I did find that if I change the font size to 8.25 instead of 9.0 the bottom of the font does not get cut off.

SDL Version

OpenTK Version (Updated with fixes resulting from this thread)

AttachmentSize
Program.cs3.13 KB

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

It's a wild guess, but could it be that the string contains some kind of termination character/sequence that is measured too? It kinda looks like as if there was an extra char in the string, or maybe a rounding error.

the Fiddler's picture

Well MeasureCharacterRanges doesn't measure \r\n\0 characters (these are positioned at (0,0)), so that's probably not it.

My guess is that the measurement is done with MeasureString while the positioning with MeasureCharacterRanges - and these two GDI+ methods return different results.

I'll write a quick test to see if that's the matter - if it is, I'll change the internal code to use MeasureCharacterRanges for everything.

Edit: Indeed, MeasureString returns different results than MeasureCharacterRanges. I am working on a fix right now.

Edit 2: Fix commited. I'm working on the cutoff issue right now.

Edit 3: All known issues should be fixed now. I still plan to make changes to this code, but it should work fine now.

JTalton's picture

Are the changes committed to the SVN repository? I grabbed the latest code and didn't see much difference with the MeasureString.

the Fiddler's picture

MeasureString should be deprecated in the latest version (or did I forget to commit that part? :) ). Try using MeasureText instead. Besides accuracy, this function can also return individual character positions, so you can place a cursor for example.

I'm cleaning up font API for 0.9.2, so expect some minor changes before the release.

JTalton's picture

Attached a new screen shot of my font test using the new MeasureText. The measurements are closer but still are a little off.
Also I was wondering about the space at the beginning of the text? Where does that come from?

Note: When I draw the rectangle to indicate the measurements I do round up the floats to the closest whole number.

I'm in no rush for a fix, so take your time and work on what you need to. Thanks!

the Fiddler's picture

Ok, I've just updated SVN to use StringFormat.GenericDefault instead of GenericTypographic, which deals with the measurement issue.

I'm still looking where the extra space to the left comes from. I suspect it could be a caused by rounding during glyph rasterization (since it's always 1 extra pixel).

JTalton's picture

I believe the GdiPlus.MeasureCharacterRanges call on the first character in the text is coming back with an offset and that is being used for the drawing thus causing the string to be moved to the right and down.

Since the rectangle returned from MeasureText has this offset set as it's location, if I adjust the position of the text before I draw it, it shows up in the right place.

the Fiddler's picture

Ok, I fixed this issue at last. You were right about the offset - the problem was caused by a mismatch between glyph rasterization and measurement. The first used a GenericDefault StringFormat, while the latter used a GenericTypographic.

Both measurement and rasterization now explicitly defines GenericTypographic, which completely resolves the measurement issues. My tests now show a tight fit for the bounding box, without cut or missing overhangs for letters. As long as the font is correctly designed, it will hopefully show up correctly.

Can you please confirm that the issue is resolved?

JTalton's picture

First font loads fine.
Second font gives a "Divide by zero exception" in LoadGlyph on the 4th character.
Out of time at the moment, I'll debug it tonight.

the Fiddler's picture

Ok, this is starting to get weird. Here is what I get after the latest updates (just checked and these *are* in SVN):

Edit: I think I'm replying to an earlier version of your post. :-) Divide by zero in LoadGlyph? The only division is by the texture size (width and height of the glyph cache), which shouldn't ever be zero - unless there's no OpenGL context (which shouldn't be the case occur, since the first font loads fine).

Any ideas how to reproduce this?