GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2013-07-10T23:44:46.000+0000 |
Affected Version/s | Release 3.1.0 |
Fix Version/s | 2013 Sprint 14, 2013 Sprint 14 API |
Components | iOS |
Labels | font, fontfamily, fonts, ios, ipad, simulator |
Reporter | Carter Lathrop |
Assignee | Vishal Duggal |
Created | 2013-05-28T13:18:37.000+0000 |
Updated | 2017-03-22T17:28:28.000+0000 |
See sample Alloy app and classic app attached for example. After opening the app in the iOS Simulator (iPad, non-retina) you'll see the text in the custom navigation bar in the renders fuzzy/blurry. It also seems like the first text label in the navigation bar is more fuzzy/blurry than the others. We're having this same problem in other parts of our app also.
More Information
It turns out that the label text only renders blurry if the parent view has an odd numbered width. This is why only certain labels were blurry and others weren't. If the parent view has an even number width then the text is not blurry. Not sure if this is avoidable or not but it is a strange occurrence.
Shawn, is this behavior only seen on alloy build apps or will the same blurry appearance occur regardless of using Alloy or not. We need this information to determine if this is an inherent problem with Alloy or with the mobile SDK. If you could look into this it would expedite the resolution to this problem a lot quicker. Thanks for your cooperation, Carter
Example in a Classic app, instead of Alloy
Hi Carter, I've attached an example Classic app to the issue that exhibits the same issues. Funny enough, different labels are blurry in the Classic example compared to the Alloy one, but both exhibit blurry labels. I've also attached screenshots from both apps so you can see the difference. Thanks, Shawn
Shawn, I seemed to have found a solution for you, take a look at this community post: http://developer.appcelerator.com/question/126216/blurry-text-on-a-textfield Specifically, this answer: I've had the same problem too for the iPad. I've managed to fix it by using even number widths. Also if you use a split view make sure in your detailNav window (the right side) use odd number widths because the black line that divides the splitview is 1 pixel making the detailNav width 447px an odd number, so any even numbers will blur the text. So it seems that when the width of the parent view of the blurry text in question was an odd number, the pixels rendered created a blurred halo around the outlines of the letters. This seems like a weird occurrence but may be unavoidable, I will relay this to engineering for them to review to see if there is a possible solution. For now, just use an even number width of the view, for instance in your tab1, I changed the width from 185 to 186 (as with rest of your tab views) and the blurriness went away:
Hope this helps! And thanks for bringing this to our attention, Carter
Hi Carter, I tried what you said and it did seem to work for the example I had provided. Once I plugged in the real labels and icons, though, it went blurry again. I decided to set all of the image widths to even numbers and I also changed the 'left' property to even numbers to no avail. I have an updated example that exhibits this behavior that I'd like to attach but it doesn't seem as though the attach functionality is available to me anymore. I see the 4 existing attachments, but there isn't an Attach button there any longer. Thanks, Shawn
Shawn, If you feel comfortable with it, you can send it to me at clathrop@appcelerator.com and I will attach it to the project myself. I have upgraded this ticket to Ti-Mobile so engineering will have a look at it and address the issue as soon as they can. I think your next step would be to see if the blurriness happens on device but other than that, there is not much more I can do from my end. Regards, Carter
Hi Carter, I just emailed over the revised example. I can confirm that it does display blurry on physical iPad devices (non-retina only) in addition to the simulator. It displays crisp on physical iPads with Retina displays and in the Retina iPad Simulator. Thanks, Shawn
Thanks Shawn, you should be able to delete the old examples. There is a small garbage can all the way to the right of the attachment description. Again, this is up to engineering to look at now so they will be in touch with their address to the issue, keep a watch on this ticket. Thanks for your patience, Carter
I'll keep an eye out, Carter. There's no trash can/delete icon next to the attachments for me. Maybe that's only for admins?
Sorry it should be right next to the time it was added, all the way to the right of the highlighted attachment. And you shouldn't have to be an admin to do it, I had another developer delete his attachments just this morning. If you still can't find it no worries. Regards, Carter
Yeah it's definitely not there. See this screenshot: http://awesomescreenshot.com/04a1cw4e0c
The attachment needs to be highlighted. See attached screenshot. If it's still not there don't worry about it, but in case you were wondering, that's how you delete attachments. Best, Carter
I tried that earlier, too. There must be some reason why it's not giving me that option. Maybe it's the same reason I no longer am able to add attachments? You can see I have it highlighted (my mouse is hovering the row) in this screenshot: http://awesomescreenshot.com/0561cwsvac .. Maybe we need a JIRA for the JIRA? lol.
That's odd... yea I'll have to write up a ticket for JIRA now. Thanks for pointing that out. Edit: Ah no, it's because the ticket is now in Ti-Mobile, a different subclass of tickets than Titanium Community. You have lost your access to make changes to the ticket. But it is strange that I am not allowed to make the changes, need a ticket for that I think. :p
Hi Carter & Ingo, Just checking to see if there's been any progress. I'm under a tight deadline to submit my app to the store in exactly one week and I can't do that with the font rendering so fuzzy. Thanks so much, Shawn
Shawn, I updated the priority to high and set severity to blocker to let engineering know this is preventing you from release. This should add some urgency to the ticket. Sorry for the wait and thanks for your patience with this. Also, if you have not already seen this Q&A post, it might help you come to a resolution: http://developer.appcelerator.com/question/126673/possible-solution-for-blurry-text Regards, Carter
Thanks, Carter. I referenced that Q&A post and I actually was able to get the blurry text to go away if I set fixed, even number heights and widths on all of the elements related to the label. This still doesn't solve my problem, though, as I need the ability to center elements and I have to set widths to Titanium.UI.SIZE to do that. Maybe the solution is to force elements that have widths of Titanium.UI.SIZE to always be set to an even number? Seems silly, but may be an easy solution.
Hi guys, We're about to deliver our application to a very large prospect on Tuesday (we have no other choice to wait any longer) and they use all iPad 2's in which our app's font will look blurry/fuzzy. Is there any chance someone can look at this and try to provide a fix before then? We're really desperate here. Thanks, Shawn
[~srahim] and [~blainhamon] Can we see if there is a quick fix for this?
Thanks for your attention to this, Ingo, Sabil, & Blain!
This is not a bug, just the way iOS draws stuff on half pixels. Lets take the example of the first custom tab which looks blurry. It has a width of 185. The tab1_interior has an autowidth of 100 [36 + 12 + 52(label)]. So with no position pins this draws the view at half pixels which causes the view to be blurry. The same is true for the retina display as well, except that the screen resolution is so high (4x pixels) you can not really see the blurred edges. The claim that the tab with an even width is not blurred is incorrect. That is blurred as well but only slightly (since only the frame.origin.y calculates to a half pixel). To prove the point just change the height of
customTab3
to 58 to see a crisp rendition of the view. To fix the issue, just give a proper top and left to all the autosized containers. You can get the approximate values from the postlayout listener on the views. I just ran the sample with the following redefinitionThe postlayout listener reported the rect property of this view to be [x,y,width,height]=[42.5,14.5,100,28] Going to mark this as wont fix since we are actually doing exactly what the code specified.
Closing ticket as the issue will not fix and with reference to the above comments.