2 related bugs with spaces and overlays

Minor issues with the Ogre API that can be trivial to fix
Post Reply
Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

2 related bugs with spaces and overlays

Post by Knotanalt » Mon Feb 18, 2013 10:13 am

First off, every overlay text is displaying two spaces instead of one for each space you see.

Turns out Jabberwocky noticed this several years ago but at least as of 1.8 it's never been fixed.
Jabberwocky wrote:I use a debug console window for testing and debugging stuff in my game. My console window uses ogre overlays. I found the following issue with space characters written into ogre overlays (ogre v1.7.1):

Every space character written to an ogre overlay window seems to render as 2 spaces. This is particularly annoying when you're trying to format text output into rows and columns. For example, if I call Ogre::OverlayElement::setCaption( "This is some text"), it renders like this:

Code: Select all

This  is  some  text
instead of

Code: Select all

This is some text
The problem seems to be with ogretextareaoverlayelement.cpp:

Code: Select all

mSpaceWidth = mpFont->getGlyphAspectRatio(UNICODE_ZERO) * mCharHeight * 2.0f * mViewportAspectCoef;
That *2.0f multiplier makes all spaces twice as wide as the other characters. This must have been an explicit change at some point, because I'm pretty sure older versions of ogre didn't have this problem. Anyway, I fixed the issue by removing the * 2.0f multiplier:

Code: Select all

mSpaceWidth = mpFont->getGlyphAspectRatio(UNICODE_ZERO) * mCharHeight * mViewportAspectCoef;
It's unclear to me if this is a bug, or is somehow desired behavior for some people. But I thought I'd at least mention it here, as it seemed relevant for this thread.
Second, it additionally returns FOUR times the proper width of a space when you call

getGlyphAspectRatio(0x0020);

I "fixed" this part by using half the space to calculate where to place the cursor in my editable fields.

Code: Select all

	float sp = f->getGlyphAspectRatio(0x0020);

	sp = sp/2.0f;
I assume these have got to just be bugs. Any chance to get this properly fixed in the next version? I don't have source control set up so I can't just check in the fixes myself without some hassle.
0 x

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 1
Contact:

Re: 2 related bugs with spaces and overlays

Post by Wolfmanfx » Mon Feb 18, 2013 10:15 am

Log it into the bug tracker https://ogre3d.atlassian.net/browse/OGRE
0 x

Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

Re: 2 related bugs with spaces and overlays

Post by Knotanalt » Wed Feb 27, 2013 1:38 pm

So I noticed it's doing something weird, using "0" to define the spacing.

So...is this even correct unicode for "0"?

#define UNICODE_SPACE 0x0020
#define UNICODE_ZERO 0x0030

Those are the ascii values. No idea what the unicode values are.

I reported it in the bug tracker, maybe I will make a thread in the help section I imagine more people will read that.
0 x

bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia

Re: 2 related bugs with spaces and overlays

Post by bstone » Wed Feb 27, 2013 2:47 pm

Those are Unicode values but happen to be equal to ASCII values as well because that just makes sense.
0 x

Knotanalt
Halfling
Posts: 94
Joined: Sun Jul 01, 2012 2:58 pm

Re: 2 related bugs with spaces and overlays

Post by Knotanalt » Fri Mar 01, 2013 2:24 am

I guess this issue with using UNICODE_ZERO is what causes the bugs. I am not sure how the spaces are supposed to be defined in a font, and guess that's a workaround for that. The space looks so big because the 0 on the font is the size of an upper case letter, making first bug.

If you ignore the spacing in getGlyphAspectRatio then when you call it after, obviously it's incorrect, making second bug. So either it should get defined properly from the font or if that's impossible for some reason the font definition should let you specify the exact spacing or else let you use the character you want (my personal workaround is to use lower case 'a' and to check for lower case 'a' when getting the glyph aspect ratio if it's a space). In any event the space displayed and the getGlyphAspectRatio should be the same.
0 x

Post Reply