Brent,
I commented out [scale = “zoomEven”] from the config.lua file to fix the problem but of course the images on screen are now stretched.
Nathan.
Hey, guys, I suddenly started seeing this slanted text on Kindle Fire simulator (not on iPhone 5 simulator). FYI, I’m using daily build 1054.
This was extremely strange and disturbing.
If I change the simulator view to iPhone 5, it won’t slant. If I switch back to Kindle Fire view, the slanted text comes back. I also checked Kindle Fire HD 7" and Kindle Fire HD 10" views, and on these HDs, slanted text goes away. (I also saw another text object that appears slanted only on Kindle Fire HD 10" view while it wouldn’t slant on Kindle Fire or Kindle Fire HD 7" views.)
I was relieved to find out that it is a simulator specific issue, because when I generated a test build to force display this particular slanted text object, it does not appear slanted on Kindel Fire device (even though it does appear slanted on simulator.)
Goodness, I spent about an hour sorting this out. I should have immediately worked on a test project to confirm this and move on, which would have taken up only about 5 minutes instead of over an hour…
Anyhow, Nathan @BoarK, your slanted text may not appear slanted on iPhone 5 device at all. As long as you don’t see the same text slanted on other simulator views, I think it’s most likely a simulator issue.
Naomi
Naomi,
That’s great to hear. I haven’t test my app on an iphone 5 yet so I can not confirm. I however got rid of the problem by using “letterBox” scaling instead of “zoomEven”. This slanted text no longer exists on the iphone 5 simulator but shows up only on the Amazon Fire HD 9.7 simulator. Strange bug but if it is a simulator only bug, as you have said, then I will worry about it later.
Nathan.
Hey, Nathan, I use letterBox scaling, and I don’t get any slanted text on iPhone 5 simulator (or at least none of the text objects I viewed on iPhone 5 simulator showed up slanted.) It was only a happen chance that I came across a slanted text object on Kindle Fire simulator today. It got me looking for other text objects and other simulator views to see what’s going on. If you are choosing to use zoomEven just because of the slanted text issue on simulator, I don’t think you need to. Unless, of course, you find zoomEven perfect for your project after all.
Naomi
Hi Nathan,
Since this seems like a possible bug on the Simulator, I just want to confirm, have you filed a bug report for it? I couldn’t get the issue to replicate in my code, otherwise I’d file the report internally.
Thanks,
Brent
Hi Brent…
maybe this snippet will show up the issue…
the slanting or skewed text shows when config set up for iphone and simulator viewed as iphone4/5/Pad etc
So, set sim as iphone and all looks fine.
window/view as/iPad and string 5 is skewed
window/view as/iphone 5 and strings 8, 10 and 11 are skewed.
window/view as/droid and strings 10,11 and 15 are skewed.
Change the font size from 10 to 12 and which are skewed changes.
I’ve included a print out of contentScaleX,Y but confess that the numbers don’t sense to me.
as yet, I don’t see the pattern in the numbers… yes, I’m fishing for an explanation… please.
Many thanks
Tim Waddy
[lua]
display.setStatusBar( display.HiddenStatusBar )
sf = string.format
function makeMultN(x,N)
return ( N * math.ceil(x/N))
end
function appendArrayBToArrayA(arrayA,arrayB)
for i=1,#arrayB do
table.insert(arrayA,arrayB[i])
end
return arrayA
end
function mkMenuBubble(inString)
print("\n\n…in mkMenuBubble … inString is ", inString)
local charSize = 10
–SLT means Single Line Text
local tmpText = display.newText(inString, 0,0, native.systemFontBold, charSize)
local SLTW, SLTH, SLTA, SLTAR = tmpText.width, tmpText.height, tmpText.width * tmpText.height, tmpText.width / tmpText.height
print(sf(“SLTW, SLTH are %s ,%s”, SLTW, SLTH))
display.remove( tmpText )
tmpText = nil
local SLTWMultFour = makeMultN( SLTW , 4)
local SLTHMultFour = makeMultN( SLTH , 4)
print(sf("Rounding UP width and height up to multiples of 4… "))
print(sf(“Expect to make text of width and height\t\t%s\t%s”, SLTWMultFour, SLTHMultFour))
menuBubble = display.newText( inString ,0,0, SLTWMultFour, SLTHMultFour, native.systemFont, charSize )
menuBubble:setReferencePoint( display.TopLeftReferencePoint )
print(sf(“In fact width and height\t\t%s\t%s”, menuBubble.width, menuBubble.height))
return menuBubble
end
function mkDictBubblesFromTabText(tableOfText)
local i = 1
for i=1,#tableOfText do
bubble = mkMenuBubble( tableOfText[i] )
bubble.x, bubble.y = 100, i*20
end
end
local testText0s = {“00005”, “000006”, “0000007”,“00000008”,“000000009”,“0000000010” }
local testText10s = {“00000____11”, “00000_____12”,“00000______13”,“00000_______14”,“00000________15”,“00000_________16”,“00000__________17”, “00000___________18” }
local testText = appendArrayBToArrayA(testText0s,testText10s)
local DeviceAspRatio = display.contentWidth/display.contentHeight
print(sf(“The device Aspect Ratio is %s”, DeviceAspRatio))
local contentSx = display.contentScaleX
local contentSy = display.contentScaleY
print(sf("\n\n\n … display.contentScaleX,Y are \n…%s\n…%s \n\n\n", contentSx, contentSy))
mkDictBubblesFromTabText(testText)
[/lua]
Hi Tim,
Thanks for the comprehensive code sample. I’ve submitted it as a bug report with the case #22695.
Sincerely,
Brent Sorrentino
Hi Brent and all,
My confession: My code sample had a bug of my own (see ** below)
My penance: Below is my work-around…
By way of explanation…
The skew/slanted text can show when simulating devices with screen sizes non-integer related to my iphone sized config (width = 320, height = 480).
Work-around Pseudo-code…
Create a tmp newText and record it’s width, then delete it.
Round up that width up to a multiple of 4. (taking display.contentScaleX into account)
Create the intended, skew immunized, near same sized text.
(My code bug **, recorded by Brent in bug report #22695 was that first tmpText had font BOLD , and the second not so.)
Executive summary: until bug fixed, I’m using the first lua snippet below: newTextSkewImmune(inString, x, y, font, charSize)
Exhastive demo: another, larger lua snippet showing problem and fix side by side.
A couple of notes:
-
Ive only tested for text lines shorter than screen width.
-
The work-around fix is really so trivial suggesting that actual under-lying bug fix should be flipped almost over-night.
(except that, of course, there will be issues I’ve not thought of)
[lua]
function newTextSkewImmune(inString, x, y, font, charSize)
local tmpText = display.newText(inString, 0,0, font, charSize)
local SLTW, SLTH = tmpText.width, tmpText.height
display.remove( tmpText )
tmpText = nil
local immuneX = (4*math.ceil(math.round(SLTW/display.contentScaleX)/4))*display.contentScaleX
local immuneY = (4*math.ceil(math.round(SLTH/display.contentScaleY)/4))*display.contentScaleY
local outText = display.newText(inString, x,y,immuneX, immuneY, font, charSize)
return outText
end
[/lua]
… and the full-on demo, side by side thing…
[lua]
display.setStatusBar( display.HiddenStatusBar )
sf = string.format
function makeMultN(x,N)
return ( N * math.ceil(x/N))
end
function appendArrayBToArrayA(arrayA,arrayB)
for i=1,#arrayB do
table.insert(arrayA,arrayB[i])
end
return arrayA
end
function newTextSkewImmune(inString, x, y, font, charSize)
local tmpText = display.newText(inString, 0,0, font, charSize)
local SLTW, SLTH = tmpText.width, tmpText.height
display.remove( tmpText )
tmpText = nil
local immuneX = (4*math.ceil(math.round(SLTW/display.contentScaleX)/4))*display.contentScaleX
local immuneY = (4*math.ceil(math.round(SLTH/display.contentScaleY)/4))*display.contentScaleY
local outText = display.newText(inString, x,y,immuneX, immuneY, font, charSize)
return outText
end
function mkMenuBubble(inString)
print("\n\n…in mkMenuBubble … inString is ", inString)
local charSize = 10
--SLT means Single Line Text
local tmpText = display.newText(inString, 0,0, native.systemFont, charSize)
local SLTW, SLTH, SLTA, SLTAR = tmpText.width, tmpText.height, tmpText.width * tmpText.height, tmpText.width / tmpText.height
print(sf(“SLTW, SLTH are %s ,%s”, SLTW, SLTH))
display.remove( tmpText )
tmpText = nil
local SLTWMultFour = makeMultN( SLTW , 4)
local SLTHMultFour = makeMultN( SLTH , 4)
print(sf("Rounding UP width and height up to multiples of 4… "))
print(sf(“Expect to make text of width and height\t\t%s\t%s”, SLTWMultFour, SLTHMultFour))
menuBubble = display.newText( inString ,0,0, SLTWMultFour, SLTHMultFour, native.systemFont, charSize )
menuBubble:setReferencePoint( display.TopLeftReferencePoint )
print(sf(“In fact width and height\t\t%s\t%s”, menuBubble.width, menuBubble.height))
return menuBubble
end
function mkMenuBubbleImmune(inString)
print("\n\n…in mkMenuBubbleImmune … inString is ", inString)
local font = native.systemFont
local charSize = 10
menuBubble = newTextSkewImmune(inString, x, y, font, charSize)
menuBubble:setReferencePoint( display.TopLeftReferencePoint )
print(sf(“In fact width and height\t\t%s\t%s”, menuBubble.width, menuBubble.height))
return menuBubble
end
function mkDictBubblesFromTabText(tableOfText)
local i = 1
for i=1,#tableOfText do
bubble = mkMenuBubble( tableOfText[i] )
bubbleImmune = mkMenuBubbleImmune( tableOfText[i] )
bubble.x, bubble.y = 80, i*20
bubbleImmune.x, bubbleImmune.y = 240, i*20
end
end
local testText0s = {“00005”, “000006”, “0000007”,“00000008”,“000000009”,“0000000010” }
local testText10s = {“00000____11”, “00000_____12”,“00000______13”,“00000_______14”,“00000________15”,“00000_________16”,“00000__________17”, “00000___________18” }
local testText = appendArrayBToArrayA(testText0s,testText10s)
local DeviceAspRatio = display.contentWidth/display.contentHeight
print(sf(“The device Aspect Ratio is %s”, DeviceAspRatio))
local contentSx = display.contentScaleX
local contentSy = display.contentScaleY
print(sf("\n\n\n … display.contentScaleX,Y are \n…%s\n…%s \n\n\n", contentSx, contentSy))
mkDictBubblesFromTabText(testText)
print(“Done”)
[/lua]
We did identify the bug and it’s been fixed in build 1088. We created a simpler test case that showed the problem. This bug has been around since build 971 (and maybe before).
Thanks,
Tom
How about that?
Yesterday’s daily build!
That’ll teach me to winge before updating.
I’ll update to today’s build 1089 and, naturally, if all works, you’ll hear nothing from me ; )
Thanks Tom.
By the way Brent, would you close bug report #22695 and as a matter of interest…
I tried to find that bug report, so that I could edit/fix it.
I couldn’t find it.
(I searched for “bug report #22695” and variations of same)
Do you think that, perhaps, among the links at the top of the “how to bug report” page
you could add a link to the list of bugs already reported/ in database?
Thanks
Tim Waddy
Fix confirmed (for build #1089)
Thanks all.
Tim