display.newText broken!

if you try this little code:

local text={} text[1]="line1\nline2\nline3\n" text[2]="line1\rline2\rline3\r" text[3]="line1\r\nline2\r\nline3\r\n" local myText={} local posX=50 for i=1, #text do local options = { text=text[i], x = posX, y = 150, --width=100, font = native.systemFontBold, fontSize = 18, align = "left" --new alignment parameter } myText[i] = display.newText(options ) myText[i]:setFillColor( 1, 0, 0 ) posX=posX+110 end

you will notice that in Android and IOS it will run different. on android it will provide linebreaks when it found “\n”. it will ignore “\r”. In IOS, it will igone “\n” and “\r”. BUT if i uncomment width line it will reconize both “\n” and “\r”. i reported the bug, and i told that ios was broken, because if should not need width to be declared to react to both. the response was that android is the one is broken, width is used for multilines so it must be declared. i’m the only one thinking this is crasy? width should be to limit chars to certain point and to alignment nothing more. display.newText should respect \n or \r without width beeing declared.

I’m sorry but I have to agree with Corona here.

The reason they need to know the width and height is because Corona don’t know what your UI looks like, and so can’t second guess it. You might think that if there is a “\r” or “\n” then it must be obeyed, but if your UI only allows for that string to be contained to one line it would reduce the quality to have the text spill onto another part of the UI. 

E.g. at the top of our screen we have a news ticker which scrolls across the screen (the white text on black bg):

VXRUlfW.png

Those strings can be pulled from a remote source, so if a “\r” or “\n” were to be placed in the string by a 3rd party we would NOT want it to force the text to multiline. 

If you don’t know what you need the width/height to be because you are not fitting the text to an existing UI, then you can set them to be full screen.

if your getting data from 3rd party it’s your job to filter undesired chars you don’t want to appear. for exemple if i use accents in a font that don’t have them or other special chars that will show ?? or other broken chars…thats the programmer job to filter those chars. it’s not the job of display.newText filtering \n. at least in my point of view…and it seams they always have done that in android version.

If the \r’s and \n’s are being processed on Android, then it’s something the OS is doing and it’s not how we built things. Multi-line text is only supposed to work if you specify a width, so we know where to wrap the text. If you do not specify a width, we assume you want single line mode, not multi-line mode. In which case, the newline and return characters should be ignored.

If this is a bug, its working wrong on Android and correct on iOS.

Rob

I’ve spoken with an Engineer and it would be good if iOS supported processing the returns and newlines, if it can. We would like you to submit a bug report for this.  Create a simple sample, probably your code above will co. The sample app needs a main.lua, config.lua and build.settings and any other things it needs. Put that in a .zip file and use the Report a Bug link at the top. We need to be able to just unzip the file, open it in the simulator, hit build install it and see the behavior.

Put a link to this forum thread in the bug report. When you file the bug report, you will get an email confirming the submission. There will be a case ID number in the subject. Please post it back here as a reference.

Rob

hi rob, like i said in my first post, i already submited a bug report. i didn’t post the case number, here it is:

caseCase 43049.

still i think android is the one is doing the correct aproach in this case. if i send \n and \r to a function that display text. it should respect that. it’s the programer job to filter then if you don’t want them to put this kinda of special chars, not the internal function. width should only limite the char limite in each line, nothing more. if i don’t specify a limite it should write all chars in the same line ofc. but still it should respect all char i put it in the string. 

i’ve no problem adding width, but in my head don’t make sense the need of it to enable a char i know it’s already there. guess android is with me in this case :slight_smile:

I’m sorry but I have to agree with Corona here.

The reason they need to know the width and height is because Corona don’t know what your UI looks like, and so can’t second guess it. You might think that if there is a “\r” or “\n” then it must be obeyed, but if your UI only allows for that string to be contained to one line it would reduce the quality to have the text spill onto another part of the UI. 

E.g. at the top of our screen we have a news ticker which scrolls across the screen (the white text on black bg):

VXRUlfW.png

Those strings can be pulled from a remote source, so if a “\r” or “\n” were to be placed in the string by a 3rd party we would NOT want it to force the text to multiline. 

If you don’t know what you need the width/height to be because you are not fitting the text to an existing UI, then you can set them to be full screen.

if your getting data from 3rd party it’s your job to filter undesired chars you don’t want to appear. for exemple if i use accents in a font that don’t have them or other special chars that will show ?? or other broken chars…thats the programmer job to filter those chars. it’s not the job of display.newText filtering \n. at least in my point of view…and it seams they always have done that in android version.

If the \r’s and \n’s are being processed on Android, then it’s something the OS is doing and it’s not how we built things. Multi-line text is only supposed to work if you specify a width, so we know where to wrap the text. If you do not specify a width, we assume you want single line mode, not multi-line mode. In which case, the newline and return characters should be ignored.

If this is a bug, its working wrong on Android and correct on iOS.

Rob

I’ve spoken with an Engineer and it would be good if iOS supported processing the returns and newlines, if it can. We would like you to submit a bug report for this.  Create a simple sample, probably your code above will co. The sample app needs a main.lua, config.lua and build.settings and any other things it needs. Put that in a .zip file and use the Report a Bug link at the top. We need to be able to just unzip the file, open it in the simulator, hit build install it and see the behavior.

Put a link to this forum thread in the bug report. When you file the bug report, you will get an email confirming the submission. There will be a case ID number in the subject. Please post it back here as a reference.

Rob

hi rob, like i said in my first post, i already submited a bug report. i didn’t post the case number, here it is:

caseCase 43049.

still i think android is the one is doing the correct aproach in this case. if i send \n and \r to a function that display text. it should respect that. it’s the programer job to filter then if you don’t want them to put this kinda of special chars, not the internal function. width should only limite the char limite in each line, nothing more. if i don’t specify a limite it should write all chars in the same line ofc. but still it should respect all char i put it in the string. 

i’ve no problem adding width, but in my head don’t make sense the need of it to enable a char i know it’s already there. guess android is with me in this case :slight_smile: