BitmapText.getLineWidth() Bug

Troubleshooting SDK
1

Hey all:

Here is a description of the issue and a test case for reproducing it.

Problem:

BitmapText crops white-space when evaluating line width. The following lines of text eval at the wrong widths:

"This is a test "
and
“This is a test”

This should show the difference in output:
[java]
BitmapText test = new BitmapText(guiFont);
test.setSize(20);

// Bitmap text without white space
test.setText(“This is a test”);
System.out.println(test.getLineWidth());

// BitmapText with white space at the end
test.setText("This is a test ");
System.out.println(test.getLineWidth());

// BitmapText with extra character after white space, then removing width of last character to compare
test.setText(".");
float charWidth = test.getLineWidth();

test.setText(“This is a test .”);

float finalWidth = test.getLineWidth();
finalWidth -= charWidth;
System.out.println(finalWidth);
[/java]

EDIT: Sorry for the extra here… I’m afraid what I am reporting here won’t make total sense. The width eval is unreliable between second and third output above, and depending on the font used, this potentially gets worse. The only reliable way of getting the actual width is to use the third example above.

2

I hit this same thing in Lemur.

There is no solution for this bug. It’s the nature of the way the font metrics work. As stated in a different thread, the issue is that in these fonts, space is reported with a width of 1 (or maybe 0) pixels. The character advance is reported properly to advance to the next character. A guess: The reported width is probably because every character has to resolve to a place in the bitmap… so the font creator would have to have given a blank area for spaces if they needed to be a bigger “width”.

The character advance is no good to include by default (and complicates the code) because some characters will report larger advances when you don’t actually want to include that in a bounding box or positioning.

I’d be 100% happy to be proven wrong but the current behavior is already a fix for oversized bounding boxes and overzealous clipping that was caused by including the character advance. When I tried to track this down for Lemur, the code was already familiar because I’d been there once before…

3
@pspeed said: I hit this same thing in Lemur.

There is no solution for this bug. It’s the nature of the way the font metrics work. As stated in a different thread, the issue is that in these fonts, space is reported with a width of 1 (or maybe 0) pixels. The character advance is reported properly to advance to the next character. A guess: The reported width is probably because every character has to resolve to a place in the bitmap… so the font creator would have to have given a blank area for spaces if they needed to be a bigger “width”.

The character advance is no good to include by default (and complicates the code) because some characters will report larger advances when you don’t actually want to include that in a bounding box or positioning.

I’d be 100% happy to be proven wrong but the current behavior is already a fix for oversized bounding boxes and overzealous clipping that was caused by including the character advance. When I tried to track this down for Lemur, the code was already familiar because I’d been there once before…

Oh… sorry, yes… I agree the character advance was to just show the difference in size. I figured that someone knew about this… but just on the off chance, I thought I’d mention it. Thank you for the quick reply!!

4

It’s a maze of twisty passages, each one alike.

Font processing is trickier than some would think… certainly trickier than the original BitmapText refactorer anticipated… and it’s been being patched ever since.

And while I’ve designed a rewrite, a) so far it has still been easier to fix the problems I find than to rewrite it (because I would want to do it properly with test cases, etc.), and b) the behavior in this case probably wouldn’t change anyway.

I do wonder if SDK generated fonts also have this problem or if it allocates space for a space in the bitmap. I suspect this problem starts much earlier as a proper translation of the AWT FontMetrics and perhaps there is no good solution at all.

5

There is no “special” handling for space in the SDK font generator. It handles it the same as any other glyph… so the advance/width/etc will all be whatever the original font defined.

6
@zarch said: There is no "special" handling for space in the SDK font generator. It handles it the same as any other glyph.... so the advance/width/etc will all be whatever the original font defined.

Yes, but I don’t know if this is better or the same as the Angelcode (or whatever) one.

7
@pspeed said: Yes, but I don't know if this is better or the same as the Angelcode (or whatever) one.

I completely forgot that this was available. The one nice aspect of the SDK one is that it won’t present you options that simply don’t apply to JME’s use of bitmap fonts.