That’s pretty small. I wouldn’t use anything less than 24 with some fonts. Really there is plenty of space for them even in a smaller texture.
Also, one real downside of the .fnt format is that it works in integers for all of its per-glyph parameters. This screws with the kerning on smaller fonts… actually I even have noticeable kerning issues on one of my 32 size fonts. I hand edited the file to fix some of the worst issues but I’ve long considered going back and making an even larger one.
The size in the .fnt controls the size of the character images in the PNG file.
…but you are right, I don’t think nifty gives a way to set the text size so it always uses what’s in the .fnt. I use nifty less and less these days so I forget. For BitmapText you can set whatever size you want.
It’s a limitation of the .fnt format that the internal offsets are all integer. Still, your problem is one of pixels and I’m not sure there is much you can do.
If you can somehow show that the font looks correct in non-JME nifty then maybe there is something wrong with JME. Otherwise, it may just be a limitation of the medium.
You could also look in the .png file that was generated with the font to see if the C and O look odd in comparison to the others.
On the font generation side you could play with the Font Smoothing and subsampling settings. Maybe they provide a more consistent result… or maybe turn off smoothing completely. (I don’t remember if it’s on by default or not.)