RTL and LTR special character

[orentu]

Hy

i use rtl and ltr character since i have english with hebrew



str1 =heb+" " ////// fix length ---> for example length =30 , space-->30-len(heb)

str1 = rtl +str1 /// heb right to left

str2 =eng+" " ////// fix length ---> for example length =20, space-->20-len(heb)

str2 = ltr+str2 /// eng left to right

strALL=str1+str2

the problem that the fixed length is change since i put hidden charater

lenght 30 is now more beause hidden rtl/ltr is turn to 32

my question is :



i need to export to txt file ascii

how an i escape special charater but not remove the new direction?

thanks

 

[NoUserHere]

See post 5 problem with concatenating number with hebrew

 

[Skydiver]

Huh? Can you show us your actual code? How did you end up with strAll having a length of only 32. It should be 52.

The following should be true:

str1.Length == 31
str2.Length == 21
strAll.Length == 52

Anyway, adding the Unicode code points lengths the string. There is nothing you can do about it because it the string length is the actual number of code points in the string, not the rendered length of the string in the UI.

See this section about string normalization. From the example strings there:

• U+1EAF
• U+0103 U+0301
• U+0061 U+0306 U+0301

each would have lengths of 1, 2, and 3 respectively even though they all represent the rendered string "ắ" .

 

[Skydiver]

I'm getting 52...

Here's the code I used to test:

const string LRM = "\u200E";
const string RLM = "\u200F";

static void ShowStringDetails(string name, string s)
{
    Console.WriteLine($@"{name}: ""{s}""");
    Console.WriteLine($"{name}.Length: {s.Length}");
}

static void Main(string[] args)
{
    var heb = "מזל טוב";
    var str1 = $"{heb,-30}";
    ShowStringDetails(nameof(str1), str1);

    str1 = RLM + str1;
    ShowStringDetails(nameof(str1), str1);

    var eng = "mazel tov";
    var str2 = $"{eng,-20}";
    ShowStringDetails(nameof(str2), str2);

    str2 = LRM + str2;
    ShowStringDetails(nameof(str2), str2);

    var strAll = str1 + str2;
    ShowStringDetails(nameof(strAll), strAll);
    MessageBox.Show(strAll, strAll.Length.ToString());
}

 

[oren tu]

Hy
what i mean is when i export to text fixed length
the position
change from 20 to 22 (20+1 specialCharac) and 30 to 31 (30+1 specialCharac)
IF I WANT TO IMPORT THE TEXT FILE to msaccess there IS PROBLEM SINCE:

POS---------LENGTH
1 ------- 20 (NOT INC SPACE 21)
22 ------- 30 (NOT FROM 21 SINCE 21 SPACE)
IN ACCESS WHEN I IMPOERT FIXED LENGTH CANT BE GAP FROM LAST AND FIRST
IN THIS CASE:
20---22

can i change back to 20 or 30 ? since is should be fix length for example 20 and not 21

 

[Skydiver]

Why do you even have to stick in the LRM or RLM characters? Most modern text renderers will automatically detect that Hebrew text needs to be rendered RTL, and that English text needs to be rendered LTR.

So basically you are at impasse. Either you stick in the direction markers which will change the string length, or you don't put them in and fix whatever is downstream that doesn't know how to handle BiDi text.

 

[Skydiver]

After having had some lunch, there is yet another alternative. Since whatever downstream is ignorant of Unicode, and BiDi, you could just use one less space. E.g.
Instead of

var heb = "מזל טוב";
var str1 = $"{heb,-30}";
str1 = RLM + str1;

var eng = "mazel tov";
var str2 = $"{eng,-20}";
str2 = LRM + str2;

Do this instead:

var heb = "מזל טוב";
heb = RLM + heb;
var str1 = $"{heb,-30}";

var eng = "mazel tov";
eng = LRM + eng;
var str2 = $"{eng,-20}";

 

[NoUserHere]

If you are using another editing engine (regardless what it is), once it's from this era, external software will auto-correct any Hebrew inputs with RTL Marks respectively. So why you are adding them in your application isn't really clear to me, or perhaps show me what I'm missing. The only reason you would add LTR Marks is if you are joining or for a better word concatenating strings which are both English and Hebrew in order to keep the text rendering order when sending those values to your external application, ie Access or other. Otherwise you should let Access handle it itself.