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
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
Hi,
Are you sure about this?
Using native.systemFont means using a different font for each device and once a text object is generated, it is a display object (image).
That aside, i’ve seen many cases where the simulator is (seem) off on text objects, especialy height and width.
I usually run an android device at the same time and when I see there is a mismatch, I create a win32 build, which often corrects the issue.
So, i trust the simulator the least 
sure.
Because for this exemple, i used “native.systemFont”, but in my real game, i used a custom font.
And the same code was working (result are the same on emulator and real devices) on the official release, and then, suddently, everything was " trim () " during a new daily build…
sounds like a bug then.
you should register it.
i don’t know how to do. I said it to Rob
if you have reported this to Rob outside this post, i don’t get the point of the post <unfollow>
to prevent other people, no ?
You’re welcome to file a bug report on this (main.lua, config.lua, build.settings and any needed assets in a .zip file --include a custom font to eliminate ) and use the Report a bug link at the top of the page, however, I’m not convinced this is a bug.
Each operating system renders text a little differently. If you’re in the simulator on a Mac and build and test on Android, you’re likely going to get different results. We have also made changes to font handling since 3068 to fix a bug where it would cut off the last character on Windows which could cause these discrepancies.
Rob
Comparing image width is quite unreliable. You can print string.len(myText.text) to see it is still 5 in both simulator and device.
this is a big problem.
try this :
local image = display.newImageRect( "Icon.png", 100, 100 ) local myText = display.newText("Test", 0, 0, native.systemFont, 18) local myText2 = display.newText("Test ", 0, 0, native.systemFont, 18) print (image.width, myText.width, myText2.width) -- result on emulator : 100 35.892055511475 35.892055511475 -- result on device : 100 33.19xxxxxxx 46.23xxxxxx
The problem is not that myText.width is not the same value on simulator and on device.
The problem is that if you add a space at the end of your text, myText.width = myText2.width on the emulator, and myText.width <> myText2.width on devices !
so everything is shifted to the screen in my game.
screenshot in the next post
Rob please can you fill a bug report for me ?
It’s a simulator, not an emulator. :rolleyes:
You can file the bug your self here: https://developer.coronalabs.com/content/bug-submission
While I have no real investment in this, I don’t believe this is a bug. Text rendering is a strange beast and is in my experience never 100% consistent between the simulator and actual devices. This is no surprise since they are two separate OSes and there are many other differences. The fonts themselves can be part of the problem.
( Rob already said this, but I think you missed it.)
Hi. You said this was a big problem, but I think it may be solvable.
I think you’re looking at this and saying, “I have problem X and I can’t solve it unless the text renders at exactly the same size between simulator and devices.”
I am saying, “Let’s examine problem X and see if there is a solution that does not rely on exact sizes.”
Please tell us why you need the text sizes to be exactly the same between simulator and device and we may have suggestions to help resolve your design issues.
Hopefully your promised screenshots will help us to help you.
submited…
how can i download a screenshot ?
Uploading Screenshots
The forums has a mechanism, but I never use it so I can’t say.
You can host the images on any site, your gitHub account, etc. then link to them with the little button that looks like a photo.
Guessing At Problem X
I’m going to go out on a limb here, but it sounds like you’re trying to achieve consistent spacing between two different text objects.
The easiest way to do this is to place the second text object relative to the first like this:
local label1 = display.newText( "Score:", 100, 100, native.systemFont, 16 ) local label2 = display.newText( tostring(100), 0, label1.y, native.systemFont, 16 ) label2.anchorX = 0 label2.x = label1.x + label1.contentWidth/2 + 20 -- 20 is a gap I have randomly selectedIf you click on “More Reply Options” by the “Post” button, you will be taken to a screen where you can attach screen shots.
As stated above, this is most likely not a bug but the fact that Android will render text differently than a Mac will. To make text work with Corona we have to use the operating system’s text rendering features to turn the text into an image. We are really at the mercy of what the operating system does. Also you are using native.systemFont which is 100% guaranteed to be different on every device. Even Apple and Google have changed the default fonts based on different versions of the OS. Some older Androids use Droid Sans, modern ones use Roboto. Amazon uses a different font on it’s Kindle Fire devices.
I know you said you’re using a custom font, this is why we asked for a demo project with the font.
Rob
Remark: it reproduces only on Windows simulator. On Mac width is different on the simulator.