I want to display slightly FROWNING face in my UILabel and the unicode whihc i am using is \u2639 but that's displaying white frowny face but i needed the yellow one. I checked everywhere but its the same unicode everywhere. could somebody tell me what is the unicode for yellow frowning face?
Edit - Attached is the screenshot for which i am looking for unicode which should be the one which i posted above but that is giving me white frowning face not the yellow one.
The slightly frowny face is U+1F641.
However, let's return to your original question. You are setting the label's text to "\u{2639}" and you are seeing the white frowny face.
The solution is to specify the variant of this glyph, like this: "\u{2639}\u{FE0F}". If you set the label's text to that, you will see the yellow frowny face.
(To understand why that is and what the variation selector means, see https://unicode.org/reports/tr51/#Emoji_Variation_Sequences. Basically, this unicode codepoint falls in the older text area, so if you want the newer emoji variant, you have to ask for it.)
But an even simpler solution is: don't use codepoint values at all! Swift strings are unicode. Just include the emoji directly in your string. Set the label's text to "☹️"! For example:
self.label.text = "☹️"
That way, you will see the emoji you specified in the string.
Related
I have a plist file which I decode to load data onto my application.
This plist file contains String type values that gets mapped to UILabel's text property.
I noticed that the truncating behavior of the text in the label is not always the same.
To be more specific, the three dots that are added when the text is truncated are, as opposed to my expectation, two kinds: one being ... and the other being ⋯ which appears to be this unicode character in this link.
I checked UILabel's attribute settings but I was unable to find any settings related to this behavior.
Has anyone else experienced this problem and standardized the truncating character to be ...?
Here is the image describing the problem mentioned above. Both labels have 2 lines and have new line escape character inserted between the first line and the second line of text. I am posting a link to this image because apparently I don't have enough reputation to post an image.
varying truncating characters of UILabel
IMO this is a bug in UILabel, and it may be worth opening a Feedback about it.
TL;DR: I recommend using TTTAttributedLabel.
Long-winded answer, because this was such an interesting question:
UILabel uses a different ellipsis based on the language script being truncated. As you've noticed, for most scripts, they use HORIZONTAL ELLIPSIS (…), or something very similar. But for Chinese, Japanese, and Korean (CJK), they use MIDLINE HORIZONTAL ELLIPSIS (⋯), or again, something very similar. The only other exception I've found is Burmese, which uses three circles that I don't recognize.
In my tests, all the following used …: Latin, Cyrillic, Bengali, Arabic, Hebrew, Hindi, Thai, Kannada, Nepali, and Mongolian (I kid. iOS can't layout Mongolian. Nobody can layout Mongolian, but it still uses …). UILabel even uses … for Lao, even though I thought ຯ was specifically for that, but I guess eventually everything becomes Latin.
The problem with UILabel being so clever for CJK and Burmese is that it decides what character to use exclusively by looking at the first character being removed. And it thinks SPACE is Latin (or at least not "special").
So what to do? My recommendation is probably to use TTTAttributedLabel, since it lets you configure the truncation character, and more importantly, is open source so you can fix it if it's not working the way you want.
The second option would be to truncate the text by hand using techniques like the one described in How to change truncate characters in UILabel?. There are probably better ways to do it using CTFrameGetVisibleStringRange instead of constantly shrinking the string until it fits, but I don't know if it's worth the effort. (If that path sounds useful, I could probably write up something that does it. It's just probably not worth the trouble.)
And the final option I know is to replace the SPACE character with an "equivalent" CJK character. The closest I've found that works is HANGUL FILLER (U+3164), but I don't like it. It's too wide, and I expect that it will make Korean uncomfortable to read (but I rarely try to read Korean, so I may be wrong here):
With SPACE: 안녕 하세요
With FILLER: 안녕ㅤ하세요
There's also HALFWIDTH HANGUL FILLER (U+FFA0), which is better, but UILabel seems to make it zero width (this may be a font issue, so maybe worth trying):
With SPACE: 안녕 하세요
With HALF: 안녕ﾠ하세요
let string = "안녕 하세요"
let filler = "\u{3164}"
label.text = string.replacingOccurrences(of: " ", with: filler)
OTOH, you may run into the same problem if you use any other non-CJK characters, like Latin punctuation or Arabic numerals. So this solution may not scale. And you should make sure that Voice Over properly ignores it.
I am trying to draw an NSAttributedString (actually, a constructed NSMutableAttributedString) where the "original" text has been struck and replacement text inserted above it (I'm trying to replicate the look/feel of an Ancient Greek manuscript).
My technique is a combination of NSBaselineOffsetAttributeName with NSKernAttributeName, but it appears that using a negative value for NSKernAttributeName "wipes away" the strikethrough of the text, even if the characters don't overlap.
If I put an extra space after the "A" character (in the original text), the "A" gets the strikethrough, but the "EI" is also offset to the right. So, it appears that the offset/kerning of the "EI" text affects how much of the strikethrough actually occurs.
Here's what I'd like to reproduce (I don't care about the angle; it's not about a picture-perfect reproduction; just the gist):
Here's what is currently happening:
This is when I add an extra space after the strikethrough:
So, the only other thing I can think of would be to render a separate NSAttributedString in the correct place, separate from the current one, but I have no idea how to calculate the location of a specific character in an NSAttributedString when it's drawn. I'm drawing to a PDF, not to any on-screen control like a UILabel. Alternatively, I could draw the "strikethrough" myself as a line, but that seems to still require knowing the coordinates for the text in question, which is calculated on-the-fly, and I hope to use this method to reproduce a large sample of ancient texts, which means doing it by hand just isn't a good answer here.
Anything I'm missing, or any out-of-the-box ideas to try?
If you include Unicode characters in an NSString, a lot of them will take on the color set for that text - they're just regular glyphs for that font so they're displayed like any other character. But there are some Unicode characters that are colored, for example GLOBE WITH MERIDIANS which is a blue gradient with shadows. But I have seen this same glyph elsewhere that's a simple black outline without a shadow, for example in the iOS keyboard. I would like to use that glyph, but without the adornments, and without having to create and use an image. I wondered if a different font would render it in a different format, and while iOSFonts.com does show different styles (bolder, italics), they're all blue. Is it possible to get the simple plain version?
Surely it is possible, because that appears to be exactly what Apple has implemented with a Tip. Notice the globe is the exact same color as the text and it's included in the string along with all the other characters. Surely that's not a UIImage?
Character in different fonts:
EDIT: The solution provided in the linked question doesn't work for this character, as the variant character appears to be the exact same as the original - blue with shadows.
Unfortunately, iOS doesn't have a monochrome globe symbol you can use; the only built-in font that includes U+1F310 GLOBE WITH MERIDIANS is Apple Color Emoji.
If you really want a font that renders this character as a simple black outline, you could package a copy of Symbola (downloadable here) into your app.
Alternatively, you could make a bitmap image with the icon you want and use NSTextAttachment to put it into an attributed string. Apple is likely doing something along these lines, as many of their Tips include symbols that are definitely not Unicode characters:
Question
Is there a definitive way to detect if the text direction in NSString or NSAttributedString is right-to-left? Text is received from external resource, not entered in the app (can't use UITextInput protocol methods).
Bad solution
I have been detecting it using CFStringTokenizerCopyBestStringLanguage() and then +[NSLocale characterDirectionForLanguage:], but it is pretty unreliable for strings, where there are only a few arabic characters and many latin. They are processes as a RTL when displayed in the label, but incorrect direction detection makes inconsistent behaviour.
Investigation
During development, I have found out that when creating NSAttributedString with no attributes except for the font and displaying it using TTTAttributedLabel, RTL text aligns to the right edge. When using simple NSString, or when using standard UILabel with attributed string, alignment stays left.
So, there has to be something in the text that says "it is RTL" and there is some method to detect it.
I analysed what I am receiving from server, and there were no standard Unicode bidi chars. This is how it looks. JSON is sent in ascii with all unicode characters escaped:
"\u0643\u062a\u0628\u062a \u0648\u0648\u062c\u0650 .."
When unescaping, it looks like this, with \u0643 is on the far right before the dots:
"كتبت ووجِ .."
As far as I can tell, every character represents a single character in arabic language, and there are no U+202B or similar control characters which could be used to easily detect direction.
Yet, when rendering this text through TTTAttributedLabel, it aligns right. I started looking into the source code, and it doesn't do anything to detect the direction or set the alignment. It only created the framesetter using CTFramesetterCreateWithAttributedString() and then, when it gets lines from it using CTFrameGetLines() and line positions with CTFrameGetLineOrigins(), they are already aligned to the right.
So, does anyone know if direction can be detected solely from the text with publicly available (and preferably fast) API methods?
Check This link that helps to you Automatically align text in UILabel according to text language
Change this for right and left alignment
if (isCodePointStrongRTL(utf32chars[i]))
return 2;
if (isCodePointStrongLTR(utf32chars[i]))
return 0;
saw this comment on other question, and thought it's important for others to check this out. this was exactly what I was looking for RTL-LTR :
"
but I've been using a solution to explicitly set the direction based on known RTL languages, which used this as a starting point:
https://stackoverflow.com/a/16309559
"
I have an iOS app which uses fixed width font label extensively.
After changing to the iOS 7 sdk and build target 6.1, all the label automagically replace occurences of three punctuation marks with an ellipsis character. This breaks a lot of stuff and looks weird, since the ellipsis character is not present in the font I use, and iOS sees fit to use one from a different font.
How do I stop this behaviour?
This is a ligature, and iOS seems to replace them automatically (like fl becomes fl). Seems like there are some options to disable them, see this question: Adjoining "f" and "l" characters
Alternative number three: insert a zero-width space (U+200B) between the dots.
(Posted as an answer per request of the OP)
One way around this is to replace the ASCII periods with a unicode 2024 character ("ONE DOT LEADER"). It looks exactly like a period but should not get converted automatically.
What you could do if this is widespread is to change all your UILabels to a subclass, MyLabel, and intercept messages to set the text, look for three dots, and if found change them to the unicode character above.
Yeah, this is a big PITA but I know of no other workaround.
EDIT
Another idea - find an open source UILabel (there must be at least one) and use it.
Another alternative : the ellipsis is a true character of its own. Why don't you try to add it yourself in your font (with Fontlab, FontForge or Glyphs) at the same width than the other characters?