I’d have to reread the code and all of the comments I left in it to answer this. At one time, I went through a fairly extensive process of rendering annotated bitmap texts and annotated Swing text and compared them… then I left comments in the code about why things are the way they are.
The biggest thing you left out in your question was kerning, by the way. You need to know that for ‘next character’.
Have you used Swing FontMetrics before or similar? Without familiarity with standard font terms then this could be a very long conversation. There are various parameters that relate a character’s ‘position’ to its extents to its ‘next position’. And while angelcode font and JME’s implementation use different terms for these sometimes, most of the important bits are represented.
Note: it can also be helpful to look at images of the letter with its letter quad edges showing and then look at the line in the fnt file to understand what the different numbers are saying. Even if you don’t take the time to write an app to visualize that stuff, a mental picture can be formed sometimes just by looking at the numbers.
Edit: fonts are one of those computer science topics that always seem like “this should be easy” and then turns out to be a lot more complicated than expected. Similar to things like time/date handling (so much trouble), color spaces, etc… (In the GIS world, datum-conversion is my favorite to point to because so many pros get it wrong, too.) So be patient with yourself as you try to figure it out.
Since x0 will have offset baked into it then we
// need to counteract that in xAdvance. This is better
// than removing it in getNextX() because we also need
// to take kerning into account below... which will also
// get baked in.
// Without this, getNextX() will return values too far to
// the left, for example.
I’m not sure how to state the differently. If you look even a few lines above you will see that xAdvance is reset to this letter’s advance before these lines happen. So each letter sets xAdvance and then we adjust it based on where the real next letter should go.
If you want to know where the next x is and are going to add xAdvance then you need to subtract the offset from xAdvance because the current x already includes that. But now I’m just restating the comment in different words.
Write a visualization or step through the debugger… else probably we can play the “me restating the comments I already wrote” a few times. I don’t mind but I feel like you will find this even more tedious than I do.
Edit: perhaps it’s important to remember the x0 is not the “text position” from a user’s perspective but the actual x position of the letter quad… which may extend left of the “text position”.
I see. I think this clears my misunderstanding a bit. Actually I was thinking the correct way is to add the xadvance (the same value that we read from the font file) to the current x0 position no matter if we have offsetted it or not.