Input:
tempTextArray:
▿ 3 elements
- 0 : "זה מבחן"
- 1 : "7 x 5 abc"
- 2 : "other text"
When doing a simple tempText = tempTextArray.joined(" | ") the result is not placing all elements where I'd expect them... result:
Printing description of tempText:
"זזה מבחן | 7 x 5 abc | other text"
its my first time combining right-to-left with left-to-right texts, has anyone dealt with a similar situation before?
My app is receiving translations from backend, so I don't know what elements are translated to (in this case) Hebrew, and which I will receive in my default language (English)
This is caused by the Unicode BIDI (Bidirectional Text) algorithm. First, I'll explain how to fix it, since it's fairly straightforward, then I'll explain what's happening in case you want more information.
You need to add LTR (Left-To-Right Mark) characters at each place you want to reset the text direction to be LTR. In your case that's at the start of the string and at the start of each | block:
let ltr = "\u{200e}"
let tempText = ltr + tempTextArray.joined(separator: "\(ltr) | ")
// => זה מבחן | 7 x 5 abc | other text
If you're going to do work with Hebrew, you absolutely want to read Cal Henderson's fantastic explanation of the algorithm: Understanding Bidirectional (BIDI) Text in Unicode.
Now to explain what's happening. You're printing a single string whose first character is the ז in "זה מבחן," and last character is the final t in "text." It is not three strings separated by |, it's just one long string. When you display that string, and the BIDI algorithm has to decide where all the characters go.
The first character (ז) is a RTL character, so it decides that this is a RTL string that has some LTR text embedded. That's the opposite of what you want. You want this to be a LTR string with some RTL text embedded. So you need to start with a LTR character such as Left-To-Right Mark.
The BIDI algorithm's job is to tell the system in which direction the next character should go. Each of the characters in זה are RTL, so that's easy, keep going left. But what about the space between זה and מבחן? Space is neutral in direction, and the last character was RTL, so the space goes to the left. But then we come to the space between מבחן and |. Space is neutral and | is neutral, so the BIDI algorithm would put the space and | to the left again. You want the space and | to be LTR, so you need to add another LTR character there.
7 is also neutral, but x is LATIN SMALL LETTER X which is LTR (not MULTIPLICATION X which is neutral).
The final result is that the BIDI algorithm decides this is a RTL string that begins 7 | זה מבחן and then is followed (to the left) by an embedded LTR string x 5 abc | other text. (In other words, this is a Hebrew string that happens to have some English in it, not an English string that happens to have some Hebrew.)
I expect what's actually displayed in your question above isn't what you're seeing (because of how BIDI algorithms get applied on Stack Overflow). I expect it actually looks like this:
And if you read this right to left, it should make more sense now what's happening.
I decided to use font-variant: small-caps for my h1 with font from google fonts ( Roboto Condensed - with latin extended characters)
On every browser it renders properly but not on Safari ( tested on macOS Sierra 10.1 )
font-variant: small-caps works as well on Safari but not with lating extended charactes. Then it just going creazy. Instead of showing "Bądźmy w kontakcie" it shows "A aa w kontakcie" or it swaps ę to some bolder ę.
How to make it work ?
It seems that fonts embeded from google fonts doesnt work for what I need. Maybe if I would attach my fonts diffrently it could work....
Anyway I decided to delete font-variant and I used text-transformation: uppercase and I changed font-size to smaller value and I have same effect that I wanted to produce.
When I try to add tab white spaces to my UILabel text in Arabic, it seems not working, while in english it's working ok:
English : (_ means white space)
col1\tcol2\tcol3\t >>>
COL1ــــCOL2ــــCOL3
Arabic
لغة۱\tلغة۲\tلغة۳ >>>
لغة۱لغة۲لغة۳
When I checked with iOS 6, I can change text size of a UITextView (not a text field) by adding attributes without any issues. (By changing UITextView's attributedText property)
For eg:
AAAAA
BBBBB
If I have above text in a UITextView, I can increase the size of the text portion of BBBB without it overlapping AAAA in iOS 6. BBBB text would increase it's size to the down side direction. Even if I increase the size of AAAA it would increase it's size towards BBBB but it would pushes BBBB text towards down to get space.
But when I run the same code in iOS 8, whenever I increase the size, BBBB part overlaps AAAA. Because in iOS 8, BBBB would change it's size to the up side direction so it overlaps AAAA text.
Is this a bug in iOS or is there a way to fix this ?
Problem solved. I had set paragraphStyle.maximumLineHeight property to the size of Font size. Removing that line did the trick.
I've tried entering the small pointing right triangle and the right arrow characters, both are converted by iOS into rectangular icons with a right triangle and a right arrow, respectively. Can I declare a different font to stop this from happening? Or is there a default setting I need to turn off?
All a want is a black small pointing right triangle:
Decimal Hex
▸ 9656 ▸ 25B8
Here is the Code:
NSString *title = [NSString stringWithFormat:#"%d payments of %# ➡ ▶", duration, [Utils formatPrice:payment]];
[button setTitle: title forState: UIControlStateNormal];
Any suggestions would be appreciated.
This is not about changing font, but about unicode variation.
On Unicode 6.1, one unicode code point can have multiple glyphs, and you can choose those using Variation Selectors.
For about emoji, you can use U+FE0E(#"\U0000FE0E") to choose text style graph.
(And, U+FE0F(#"\U0000FE0F") is for Apple Color Emoji).
For example, LEFT-POINTING TRIANGLE's unicode code point is U+25C0(#"\U000025C0"), and you can specify not to use Apple Color Emoji but non-color symbol like #"\U000025C0\U0000FE0E".
Also, there is some difference between iOS emulator(for iOS6 on Mountain Lion) and actual device(iOS6) about Variation Selector handling, probably because Mountain Lion have more support for Unicode 6.1, I guess.
For example, if I don't specify the selectors, I see non-color triangle on iOS6 device, but Apple Color triangle on iOS6 simulator(on Mountain Lion), for UIBarButton.
So, it is nice to check both simulator and actual device, but it looks more safe to use Unicode Variation Selectors always anyway.
It was kind of challenging to force the Browser to render the HTML Entity on iPads/iPhones, but I managed to find the solution, and here's the trick.
Instead of using HTML entities directly:
◀ <!-- ◀ BLACK LEFT-POINTING TRIANGLE -->
▶ <!-- ▶ BLACK RIGHT-POINTING TRIANGLE -->
I created supportive elements in HTML, with the classes:
<span class="left-pointing-triangle"> </span>
<span class="right-pointing-triangle"> </span>
With the use of CSS ::after pseudo-element made the override of the content:
.left-pointing-triangle::after {
content: "\25C0 \FE0E";
}
.right-pointing-triangle::after {
content: "\25B6 \FE0E";
}
The important part is to use content: "\25C0 \FE0E", instead of just symbol itself content: "\25C0". It works flawlessly on both iPads and iPhones of different iOS versions.
I use these unicode characters to stop iOS from fiddling:
Right-triangle: ► (►)
Left-triangle: ◄ (◄)
Update
If further triangles are what you seek:
Up-triangle: ▲ (▲)
Down-triangle: ▼ (▼)
To show the black right arrow emoji, we should choose ▸ instead of ▶ or ► in order to avoid Apple Emoji
▸ is smaller than the other two, but you can set the font-size to adjust it.
Works for me.
You can render small triangles in SVG on modern browsers.
Right Triangle:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="8" height="16" viewBox="0 0 5 10">
<polygon fill="black" points="0,0 5,5 0,10" />
</svg>
Left Triangle:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="8" height="16" viewBox="0 0 5 10">
<polygon fill="black" points="0,5 5,0 5,10" />
</svg>
That appears to be the system font glyph for 25B8. I would assume the same would happen for 2B05 (Leftwards Black Arrow) and 25C0 (Black Left-Pointing Triangle). They are apart of Apple Emoji.
You may want to try using a different font.
Hope that helps.