display.newText alignment differences on IOS vs Android

[carloscosta]

Hi.

i discovered that some fonts (well not some, a lot of them) display different from Android and IOS.

Same code, same font, different output alignments.

i’ve made a simple code to test this:

--------------------------- version 1 -- no text height defined -- no text width defined -- rect anchorY=0.5 -- text anchorY=0.5 local font=nil -- change this to test fonts ---------------- local rect=display.newRect(100,100,150,30) rect:setFillColor(0.5,0.5,0.5) local params={ text="HELLO WORLD!", fontSize=18, x=100, y=100, font=font } local text=display.newText(params) --------------------------- version 2 -- no text height defined -- no text width defined -- rect alignY=0 -- text alignY=0 ---------------- local rect=display.newRect(100,150,150,30) rect:setFillColor(0.5,0.5,0.5) rect.anchorY=0 local params={ text="HELLO WORLD!", fontSize=18, x=100, y=150, font=font } local text=display.newText(params) text.anchorY=0 --------------------------- version 3 -- text height = 30 -- text width =100 -- rect alignY=0 -- text alignY=0 ---------------- local rect=display.newRect(100,200,150,30) rect:setFillColor(0.5,0.5,0.5) rect.anchorY=0 local params={ text="HELLO WORLD!", fontSize=18, x=100, y=200, width=150, height=30, font=font } local text=display.newText(params) text.anchorY=0 --------------------------- version 4 -- text height = 30 -- text width =100 -- rect alignY=0 -- text alignY=0.5 ---------------- local rect=display.newRect(100,250,150,30) rect:setFillColor(0.5,0.5,0.5) rect.anchorY=0 local params={ text="HELLO WORLD!", fontSize=18, x=100, y=250, width=150, height=30, font=font } local text=display.newText(params) text.anchorY=0.5 --------------------------- version 5 -- no text height -- no text width -- rect alignY=0 -- text alignY=0.5 ---------------- local rect=display.newRect(100,300,150,30) rect:setFillColor(0.5,0.5,0.5) rect.anchorY=0 local params={ text="HELLO WORLD!", fontSize=18, x=100, y=300, font=font } local text=display.newText(params) text.anchorY=0.5 --------------------------- version 6 -- text height = 30 -- text width = 150 -- rect alignY=0 -- text alignY=0 ---------------- local rect=display.newRect(100,350,150,30) rect:setFillColor(0.5,0.5,0.5) rect.anchorY=0 local params={ text="HELLO WORLD!", fontSize=18, x=100, y=350, width=150, height=30, font=font } local text=display.newText(params) text.anchorY=0

if you change the line “local font=nil” to any font you have in your resource directory to test. you will encounter different outputs on Mac/IOS Vs Windows/Android.

this is a known issue? i know that with default fonts it works on both like it should. i don’t know why it doesn’t work on all fonts like it should (i’m asking to much?). any logic explanation for this to happen?

the only thing that i change is width, height, and anchorY.

[iandunbar]

I have also been experiencing some font irregularities between different platforms, it would be great to see if there were any more info on this potential issue.

[rob]

There are a couple of different things going on here. Lets start with the one we can’t do anything about.

1. display.newText() uses the operating system’s native text rendering to return an image that we use as part of our OpenGL display hierarchy. Each operating system renders the text a little bit differently. Android tends to put more padding than iOS does (I think its that way) in the image. There isn’t anything we can do about this. Also the less professional the font’s creator (foundry) is, the more likely it is to have errors and inconsistencies in the font file. For instance all Adobe fonts might have their baselines and such standard where the font from a random person might not have those font metrics correct.  There will be variation between platforms and free fonts tend to exaggerate those variations.

2. The second thing is how you’re using both anchor points and display.newText() is both single line and multiline modes.

When you do not specify a width and height,  the bounding box of the font should be tight around the text (+ any padding from #1 above). Like other display objects, it’s x and y are it’s center unless you change things.

In your first example you have a single line text. You draw your box centered at 100, 100. You also draw the center of your text box at 100, 100. This fits perfectly in the box.

The section example is also a single line text that you’re anchoring to the top. Y = 150 on the box means draw the top of the box at 150. You also have an anchorY of 0 on the text. Which you would expect to be flush against the top of the box, but because there is a little padding around the box (and varies on different platforms) it’s offset just a little bit. Some of that padding could be due to potential extenders and decenders the font may need to deal with.

The 3rd example switches to multiline text. In this case you are going to get back a 150x30 image. The default for multi-line text is to left justify it. Since the anchor points on the box and the text are the same, the boxes are drawn directly on top of each other. The text is properly left justified. There is some padding variance between the platforms.

In the 4th example, you change the anchor point of the box to be centered instead of from the top, shifting it 15 pixels lower than the text.

Version 5 and 6 are more of the same, one is single line, the other is multi-line.

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

Rob

[iandunbar]

Thanks Rob! The first point addresses my issue as additional padding would cause the problem that I am seeing.

[carloscosta]

When I do not specify a width and height in a native font i’ve same results on both plataforms (0 padding on both) only on custom fonts i’ve this problem. the images i’ve upload are from a custom font, you have the exact same result on native fonts on IOS or Android. 

even if you can’t do much about it, because of different platform rendering , there is one thing corona can and should have done already (knowing this issue). introducing padding to properties in display.newText.

[iandunbar]

I have also been experiencing some font irregularities between different platforms, it would be great to see if there were any more info on this potential issue.

[rob]

There are a couple of different things going on here. Lets start with the one we can’t do anything about.

1. display.newText() uses the operating system’s native text rendering to return an image that we use as part of our OpenGL display hierarchy. Each operating system renders the text a little bit differently. Android tends to put more padding than iOS does (I think its that way) in the image. There isn’t anything we can do about this. Also the less professional the font’s creator (foundry) is, the more likely it is to have errors and inconsistencies in the font file. For instance all Adobe fonts might have their baselines and such standard where the font from a random person might not have those font metrics correct.  There will be variation between platforms and free fonts tend to exaggerate those variations.

2. The second thing is how you’re using both anchor points and display.newText() is both single line and multiline modes.

When you do not specify a width and height,  the bounding box of the font should be tight around the text (+ any padding from #1 above). Like other display objects, it’s x and y are it’s center unless you change things.

In your first example you have a single line text. You draw your box centered at 100, 100. You also draw the center of your text box at 100, 100. This fits perfectly in the box.

The section example is also a single line text that you’re anchoring to the top. Y = 150 on the box means draw the top of the box at 150. You also have an anchorY of 0 on the text. Which you would expect to be flush against the top of the box, but because there is a little padding around the box (and varies on different platforms) it’s offset just a little bit. Some of that padding could be due to potential extenders and decenders the font may need to deal with.

The 3rd example switches to multiline text. In this case you are going to get back a 150x30 image. The default for multi-line text is to left justify it. Since the anchor points on the box and the text are the same, the boxes are drawn directly on top of each other. The text is properly left justified. There is some padding variance between the platforms.

In the 4th example, you change the anchor point of the box to be centered instead of from the top, shifting it 15 pixels lower than the text.

Version 5 and 6 are more of the same, one is single line, the other is multi-line.

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

Rob

[iandunbar]

Thanks Rob! The first point addresses my issue as additional padding would cause the problem that I am seeing.

[carloscosta]

When I do not specify a width and height in a native font i’ve same results on both plataforms (0 padding on both) only on custom fonts i’ve this problem. the images i’ve upload are from a custom font, you have the exact same result on native fonts on IOS or Android. 

even if you can’t do much about it, because of different platform rendering , there is one thing corona can and should have done already (knowing this issue). introducing padding to properties in display.newText.