Curious to know how to calculate the width of a text (single-line text) in bitmap font?
Accumulating xAdvance of all letters?
or
Accumulating xAdvance + xOffset of all letters?
or another way?
next question, if we have xOffset and xAdvance of characters how do we find the x position of the next character? (In both left-to-right and right-to-left fonts)
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.
I read about kerning. Suppose kerning is 0 for all characters. By this assumption can we still tell which one is correct for calculating the line width?
Because of why the comment says. But this is what I was talking about as the difference between letter quad and letter position, etcâŚ
Basically, the letter quads overlap. The first letter sticks out to the left of the text position. So if you want to know the text width then you have to include that bit.
Whatâs fun is to create a visualization where you put a marker at each character position and render the outlines of the quads of the letters. Things become much clearer, I think.
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.