My app uses unicode characters. These characters (not the actual codes) are pasted directly into a PLIST file and then imported.
Some of them are not appearing correctly in UILabel and UIButton
When I print them to the log in Xcode they appear normal, but when displayed on the iPhone/Simulator some of the characters turn into an "alien in a box".
See image for example of problem (screenshot from UIButton titles)
My guess is that the font you are using does not define these characters. Select a font (or build one into your app) that includes the characters you need.
Related
I have an issue with an icon font not displaying on iOS 12 (it works perfectly fine on iOS <= 11). A few more details on what I've found and how we use the font:
1) The font is properly included in the project and it appears when NSlogging [UIFont familyNames] and [UIFont fontNamesForFamilyName:iconFontFamilyName]
2) I'm accessing the icons using the \u notation: label.text = #"\uXXXX". When XXXX does NOT exist in the font, the app displays the "question-mark-in-a-square", indicating (correctly) that the code does not exist. However, if the code DOES exist in the font, then the app displays nothing at all - the respective element appears blank.
Is there something we're missing here?
In summary, the issue is most likely with Icomoon's font generation; specifically the types of cmap encoding subtables. I would suggest two actions:
Test this hypothesis by using a font conversion tool (such as https://onlinefontconverter.com) to convert your ttf file to otf (which is also supported by iOS).
If your glyph displays then continue to use your new otf file while raising the issue with IcoMoon directly.
I remember having a similar issue when playing around with on-device font generation in my MinimumRubber project. I found that careful choice of platform identifier and platform-specific encoding identifier were required for both UILabel and UITextView to display the glyph. It does not surprise me that Apple has refactored this area of code
I have a UILabel with Arabic text which contains the word اسماً, last character is the letter Alef with the mark Fathah. This mark is somehow causing the word to be misaligned vertically with the rest of the text.
When removing the mark, the word is back to correct baseline
The font is iOS system font, this doesn't happen with the Ariel font.
This is an issue with the iOS system font.
I've opened a new project to test it and added only a UITextField with an Arabic string which includes the char اً as the placeholder and it had the same behaviour.
This has been fixed on iOS 11.
I would like to get a down arrow to display inside a UILabel. Specifically ⬇ Unicode: U+2B07. This is show sort order on a column header.
I have seen the code to get unicode characters to display and when I use it for the symbol above it doesn't display as expected but rather comes up with a blue down arrow with gloss.
Has anyone seen this?
Displaying some characters as "Emojis" is a feature which is e.g. (controversially) discussed here: https://devforums.apple.com/message/487463#487463 (requires Apple Developer login). This feature was introduced in iOS 6.
A solution (from https://stackoverflow.com/a/13836045/1187415) is to append the Unicode "Variation selector" U+FE0E, e.g.
self.myLabel.text = #"\u2B07\uFE0E";
// or:
self.myLabel.text = #"⬇\uFE0E";
Note that on iOS <= 5.x, the Variation selector is not necessary and must not be used, because iOS 5 would display it as a box.
In Swift it would be
myLabel.text = "⬇\u{FE0E}"
If you're seeing the blue arrow with gloss, you have the right character, but it's showing one of the emoji-style characters. Try changing the font of your UILabel to something like Arial Unicode MS.
Edit After a little testing, it looks like changing the font doesn't actually work. It keeps displaying the glossy arrow. It's probably better to go with the suggestion of the other answer and use a different glyph, like \u2193, which does work:
[nameLabel setText:#"\u2193"];
When I write arabic text containing the letter kasra (unicode character 0x650, phonetic equivalent i) to a button, the kasra is not displayed. Thus, the word mumkin appears as mumkn. If I inspect the NSString in Xcode, the kasra is present, but the kasra is not displayed in the iPhone simulator or on a real iPad. The other two short vowels (fatha and damma) are displayed correctly.
The arabic letter kasra (unicode character 0x650) is missing from all of the built-in IOS7 fonts that i have tried.
The solution was to build a different font into my app- I used AGA-Rasheeq-Bold.
This may be a bug. I just tried it in the storyboard editor and it does not seem to work. I created a string in the MAC Notes application, copied and pasted. It displays correctly in the left hand properties panel, but not in the button itself. Could you provide the exact Unicode string? You may need to open a bug report with Apple.
I can confirm that it works correctly in a Label field, but not a Button (IOS 6.1 and Xcode 4.6.3)
Try attributed text. This seems to work around the issue.
I've always thought it was great that I could use simple iconic unicode characters in a string when I needed an arrow or a bullet or whatever. The glyphs would render in the same color as the rest of the string with a nice simple and clean icons. I could preview how they'd look by using the Mac's "Special Characters" dialog on the Edit menu in XCode.
In iOS5, these glyphs render in full color and aren't simple and clean. I believe these are Emoji icons?
I'm looking for an explanation of this change, and ideally how to force iOS5 to revert to the iOS2 - iOS4 behavior.
Here's an example: #"← left arrow, right arrow → airplane ✈";
Edit:
Apparently the NSString UIKit extensions for rendering text (drawAtPoint: / drawInRect:) don't exhibit this behavior. So perhaps it is a UILabel thing? Specifically I've noticed it inside a UISegmentControl segment button, and in a UILabel.
This isn't a bug, it's down to the font used. When you use a character in a string that isn't available in the chosen font, iOS automatically substitutes a glyph from another font.
The system font (Helvetica) doesn't have those characters in it, so I'm guessing that Apple have have changed the list of fallback fonts so that Emoji ranks above whatever it was using previously for the fallback for those characters.
To fix it, find a font that a) has the version of the characters you want in it, and b) is available on iPhone, and set your label to use that instead of the default system font.
Alternatively, you could just make a UILabel subclass and override the drawRect method so it uses the drawAtPoint/drawInRect methods to draw the string.