[SORTED] Text inside native.newTextField object does not scale with the device

Solar2D Daily Builds and Public Releases
#1

I noticed that with native.newTextField, the font size of the text I enter in the field does not scale with the device. What I mean is, I set the font size to look good inside the field on iPhone device – but when I look at it on iPhone4, iPad or iPhone Retina, the text looks very small.

It would be nice if this is fixed soon. Or do I need to capture the screen resolution and specify the font size dynamically to work around this issue?

If this issue can be fixed soon, I’d rather not to add this workaround. Please advise.

Naomi

Edit: bug report submitted with sample project. Case# 16571. [import]uid: 67217 topic_id: 29818 reply_id: 329818[/import]

#2

+1000

Makes my nice biz app look goofy on the iPad.

Jay
[import]uid: 9440 topic_id: 29818 reply_id: 119586[/import]

#3

+1000^2 [import]uid: 13784 topic_id: 29818 reply_id: 120157[/import]

#4

In my app I set, at the very beginning, a “scale” var - which basically is 10 divided by the *physical" size of the device (of course, to do that, I have to have a LONG list of device models from system.getInfo(“model”) with their physical sizes).

I use letterbox scaling, and I use that scale var to increase the scale of UI objects (with the “normal” scale being whatever looks good on iPad screen) - like a wheel picker for example, since on smaller (physically, not resolution-wise) devices those UI objects have to be proportionately bigger, since human fingertips do not scale down very well.

For the newTextField font, though, I found that I have to *divide* the font size by that scale in order to get the same effect. That’s because the letterbox scaling does NOT affect the font size of the text field, the font size you assign is absolute. [import]uid: 160496 topic_id: 29818 reply_id: 120172[/import]

#5

+1000

Makes my nice biz app look goofy on the iPad.

Jay
[import]uid: 9440 topic_id: 29818 reply_id: 119586[/import]

#6

Yup - that’s exactly the problem.

Font sizes in native text elements are “immune” (if you will) to Corona’s scaling because they are within the footprint of the “native” element.

It is also a problem if you DON’T use Corona scaling as Corona doesn’t account for the pixel & point density standard.

In other words, on a Samsung Galaxy Tab 7 with a point density of 1.5 versus an ASUS Transformer with a point density of 1, fonts in native UI elements are all jacked up.

On Apple, this manifests itself with the new iPad and it’s point density of 2. [import]uid: 13784 topic_id: 29818 reply_id: 120389[/import]

#7

I just found this great tutorial blog post by Jonathan: http://www.coronalabs.com/blog/2012/02/07/tutorial-text-input-with-native-ui/

It seems like the best workaround for my case would be to use the tip under Not Normal Display Objects! that says:

Use rectangles, rounded rectangles, and text objects to serve as “placeholders” for your native objects. When a user touches the placeholder, display the native object directly above while the user is editing. When the user finishes, update the placeholder to match and remove the native object.

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120500[/import]

#8

That’s fine, Naomi, but the issue of the font size *while editing* is still there. [import]uid: 160496 topic_id: 29818 reply_id: 120502[/import]

#9

Yeah, @mike470, I thought about it too – and am thinking of updating the placeholder text during the “editing” as well as “ended” & “submitted” phases. That said, I’m going to put this problem aside for a while until I’m mostly done with the project and ready to polish the overall look & feel. I’ll tackle this problem then because aside from this issue, the screens with textfields are working as expected, and I’ve got whole a lot more to do still. (Who knows, this workaround may or may not work out as well as I would like… but until then, I’m going to hope for the best.)

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120503[/import]

#10

I spent a LOT of time this weekend focusing on this and have a complete workaround to these bugs.

My text boxes always have perfectly sized text now. [import]uid: 13784 topic_id: 29818 reply_id: 120505[/import]

#11

@marble68, glad to hear you’ve got yours working perfectly now. Would you mind sharing some tips on what to avoid and what to do in general? Would the idea of updating text placeholder object during editing/ended/submitted phases a good idea?

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120507[/import]

#12

Wow, @marble68, thank you for sharing your thoughts and detailed explanation. I really appreciate it. And yes, I do use Corona’s scaling, so your solution wouldn’t work for me (and Corona’s scaling has done well by me so far.) I’ll experiment when I’m ready to tackle it.

Thanks again!

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120513[/import]

#13

See above: it’s the point density. That is the key.

http://www.alistapart.com/articles/a-pixel-identity-crisis/ explains it

this wiki article helps:
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density#Samsung

Note, that on iOS, the point density is *always* 1 (according to Corona, which is wrong [a symptom of the problem]). Even if it’s two, Corona sees it as 1. On the new iPad, the density is really two, so you have to double your font size.

Like this psudocode:

local RetinaTextSizeMultiplier()  
 if ThisIsARetina==true then  
 return 2  
 else  
 return 1  
 end   
end  
  
local fontsize = 18  
myField.font = native.newFont( native.systemFontBold, (18 \* RetinaTextSizeMultiplier) )

Lucky for us, there’s only four Apple devices we have to accommodate. :slight_smile:

Android is different. Like Mike says…
[text]
I found that I have to *divide* the font size by that scale in order to get the same effect
[/text]

You have to have the point density. Lets say it’s 1.5. If the display.contentHeight is 1024, the REAL content height is 1024 / 1.5 = 682. If your font was supposed to be 20 (~20 pixels high), that’s ~.02 of 1024. With a point density of 1.5, your font needs to be .02 of 682 (or 14).

Now, this is *EXTREMELY* important - I do NOT use Corona scaling. I do all my own - so your mileage may vary GREATLY if you do. I know you do, Naomi, as you’ve said as much. The logic may be the same if Corona is scaling and reporting contentHeight as 480. I just don’t know.

I am of the belief, though, that native UI elements ignore Corona’s “scaling.” I am almost sure of it.

THIS is the bug in Corona. Corona deals in *pixels*, not points. Native Textboxes, though, deal in points.

What Corona Labs should do is put a wrapper around this object in the Corona Library, determine the point size of the device, and accommodate it accordingly. But it has to work with corona apps that DON"T use Corona scaling or that’d be disastrous.

I have invested A LOT of time to build my own generic wrapper, easily 30+ hours.
[import]uid: 13784 topic_id: 29818 reply_id: 120512[/import]

#14

I just posted about this issue on my FAQ Wednesday blog. http://www.coronalabs.com/blog/2012/08/22/faq-wednesday-mac-simulator-and-native-fonts/

The bottom line is Corona does not scale fonts for native objects because of the different metrics for each font family causes differences between fonts if we tried to scale it the same way as we do the rest of the Corona display objects. This is not an issue with display.newText because it’s converted to a bit map and then scaled as if it was an image (which still may not be ideal for certain font families).

One possible solution to scaling fonts for native text objects is creating a display.newText object with the same font to be used in the native text object and read the contentHeight. You can then apply the current scaling factor for the screen to the contentHeight value and use that to adjust the native font size for native text objects. You would then remove the display.newText object. Anyway, just a thought if you want try this in your own app

-Tom [import]uid: 7559 topic_id: 29818 reply_id: 120782[/import]

#15

Thank you, Tom! I’m thinking of creating dummy display objects (graphic object + text object) and set the alpha of the native.textField to 0 (as suggested by the tutorial Jonathan posted a while back – see my post #5 above.)

That said, I made a mental note of your comment that says: _ “We may try to address this issue in future builds with the option to disable the feature in case of the above issues.” _

It sounds great to me, and maybe, just maybe, it will become part of the native.textField before I implement the workaround. :wink:

Thanks again.

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120789[/import]

#16

FYI, my actual solution for this “issue” is something like below and it works quite nicely so I see no problems with it anymore.

[lua]if system.getInfo(“model”) == “iPad” then
textFieldFont.size = 32
else
textFieldFont.size = 18
end[/lua]

Done!
Cheers,
Rodrigo. [import]uid: 89165 topic_id: 29818 reply_id: 120810[/import]

#17

That works great, unless you use a custom font and font size and don’t use scaling.
On iOS devices this is much less of an issue - but on Android the font size can be really messed up because of point differences.

I know the Corona team is working on it from emails.

Should be a non-issue soon enough! [import]uid: 13784 topic_id: 29818 reply_id: 120811[/import]

#18

Thank you, Rodrigo. I would consider it as an option (and thought of doing it), except that I’d like to set up my code to accommodate for both iOS and Android (including Kindle & Nook) versions (although I’m primarily focused on iOS version right now). This sort of makes it not an option for me after all.

I really appreciate you mentioning it, though.

Naomi [import]uid: 67217 topic_id: 29818 reply_id: 120812[/import]

#19

@Naomi , no problem at all. :slight_smile: And yes, I can see what you mean regarding the variety of systems and device`s screens - pain and more work. :S

@marble68 I understand what you mean. Android is a really fragmented world and so it brings many “new issues” all the time for us cross-devs, you`re right.

PS: My snippet code above is being used mainly for iOS and so it does handle that OK but if I go into the Android`s side I can really understand that it would be much worse surely.

Thanks all Corona Devs for sharing here your own issues & solutions as well.
Cheers,
Rodrigo. [import]uid: 89165 topic_id: 29818 reply_id: 120813[/import]

#20

+1000^2 [import]uid: 13784 topic_id: 29818 reply_id: 120157[/import]