New bug : width for a text with blank char

Difference at screen for me between “simulator on windows” (with shift), and all other platforms (see attached image) :

  • simulator on mac = ok
  • device iphone = ok
  • device android = ok
     
    ok this is not a big big bug and i can bypass it and found a solution to avoid to add blank spaces at the end of my text, but in all case this is a real bug when a = b on a platform, and then a <> b on another one !
     
    so the problem seems to be only on the simulator running on windows who “trim” the text.

nice description of the bug :

 local native\_1 = display.newText("a test" , 0, 0, native.systemFont, 18) local native\_2 = display.newText("a test ", 0, 0, native.systemFont, 18) local perso\_1 = display.newText("a test" , 0, 0, MY\_FONT, 18) local perso\_2 = display.newText("a test ", 0, 0, MY\_FONT, 18) if native\_1.width == native\_2.width then print("Bug!", native\_1.width, native\_2.width) else print("OK", native\_1.width, native\_2.width) end if perso\_1.width == perso\_2.width then print ("Bug!", perso\_1.width, perso\_2.width) else print ("OK", perso\_1.width, perso\_2.width) end --[[simulator on windows : Bug 44.437782287598 44.437782287598 Bug 47.856071472168 47.856071472168 simulator on mac : OK 44 50 OK 48 54 device iphone : OK 43.86xxxxxxx 48.60xxxxxx OK 48.60xxxxxx 53.34xxxxxxx]]--

So Rob, not a bug ? :slight_smile:

The solution I gave you can be used to resolve this.

Simply do this:

  1. place the coin image relative to the edge of the button.

  2. create the text label

  3. Set the text label’s anchorX to 1

  4. Place it relative to the coin’s position, minus its width and an extra buffer.

You can also do more complicated (still easy) calculations and make the text and coin nicely center on the button.

This might help: https://coronalabs.com/blog/2014/02/11/tutorial-methods-for-positioning-text/

Was away, for a bit and I had another thought.

If you absolutely want to have consistent text, you can use a bitmapped font.

In short, you use a tool (free or paid) to generated a texture sheet of images, one per letter.  Then use that and (free or paid) libraries to display text using the images.

It is bit of work to get started on this, but once you have the process down you’ll find this gives the absolute best results.

BTW, I don’t think any of us considers this a bug.  This is just a fact of life when using fonts between different OSes. 

This is similar to the fact that 

Lastly, I suggest NOT front- or end-padding with spaces and instead using the aforementioned advice on positioning text objects.

PS - Consider that this is not the only ‘thing’ you will find varies across OSes.  Another often bemoaned variance is

math.random()

This function will return different sequences for the same seed on different OSes.  The reason is the same as this variance for text.  Different OS + different libraries + slightly different implementation equals variance.

It is normal that math.random starts with different numbers and show different sequence of Numbers : very obvious.

But It is NOT normal that something (working perfectly in the last official version), now doesn’t work only on the simulator of Windows, on the last release.

So ok there are solution to bypass this pb or to make a better code without using spaces.
But this is not a “fact of Life”, this is a bug which certainly will be corrected soon

Our engineering team is looking in to it, and the default on Windows appears to trim white space and they are looking at changing that.  

However that said, using spaces to pad things isn’t the best practice. It’s best to either use a text with no space and use anchor points to position things.  Or define a fixed width for the text with a left, right or center justification and let display.newText() guarantee your text size.

Rob