XtraReports RTL: bidirectional text drawing

Hi dev
Although i understand the difficulties in this issue, (you are working on rtl support for about 10 years)
i cannot accept this answer has the development team leader in my company.
i urge you to go faster and better.
btw in other subject i appreciate your work alot and my webapplications works much better thanks to your controls flexbilty.
but this is close to a dill breaker
best regards
nir tregerman
Software Development Manager
QaOnline

Nir, I understand your position. As I mentioned, we're going through internationalization improvements and the RTL support near the top of our priority list. Please note that the capability to draw RTL text (I'm not talking about the UI here) was always presented in our XtraReports Suite. As you know, there are a set of non-printable Unicode characters which allow you to assign a direction to a text block, paragraph, or document. For instance, let's review the example from the Right-to-left mark Wikipedia article where Hebrew text is inserted into an English paragraph. The paragraph in this case is LTR (since it starts from the LTR character), but we would like to render the exclamation mark at the beginning of the Hebrew text. So, technically speaking, we're required to specify the direction for this neutral block containing the exclamation mark using the Right-to-Left embedding character (to simulate the presence of an RTL paragraph) and then insert the PDF (Pop Directional Formatting) character to mark the end of an embedded section. I've attached a small example to illustrate how this technique would look like in code using our reporting components. Of course, it's not as convenient as specifying the text direction manually through the UI facilities, and I cannot claim that this approach would work correctly under any possible scenario. Still, I hope you find this workaround worth considering as a temporary solution until the RTL support is officially implemented.
Feel free to contact us at any time.

hii  yaroslav
thank you for the detailed answer.
this workaround is something i considered in the past with no succsess.
anyway it works fine and can hold as a workaround as a temporary solution
except one problem: when saving as pdf the text within the special chars disappers.
thank you very much for the effort
nir

I'm happy to hear that you found my workaround worth reviewing, Nir. The PDF export issue you've mentioned is more about the font currently being used rather than the RTL specifics. As you know, in order to display text correctly, PDF needs access to a font that supports the characters used in a document. And the point is that the font I'm using (Verdana) doesn't have those Hebrew characters - they are displayed in the print preview only because the GDI+ library is capable of substituting characters of a similar type font at runtime. Try out another font (e.g., 'Arial Unicode'), and you'll see that those LTR characters are exported correctly as expected.
If there is anything else I can help you with, let me know.

hii devex, Yaroslav
i've succeeded to create a workaround which works fine in must cases.
it's still in testing phase.
i want to thank you your effort and time.
nir.
btw its something like that :
(it assume that must of the text is in RTL Language)
(the regex catches also space to fix situations of more that one LTR word togther)

C#
public static string FixBiDirectionalString(string Text)  
      {  
          try  
          {  
              char RLE = '\u202B';  
              char PDF = '\u202C';  
              char LRM = '\u200E';  
              char RLM = '\u200F';  
              StringBuilder sb = new StringBuilder(Text.Replace("\r", "").Replace("\n", string.Format("{0}", '\u000A')));  

              System.Text.RegularExpressions.Regex r = new System.Text.RegularExpressions.Regex("[A-Za-z0-9-+ ]+");  
              System.Text.RegularExpressions.MatchCollection mc = r.Matches(sb.ToString());  
              foreach (System.Text.RegularExpressions.Match m in mc)  
              {  
                  double tmp;  
                  if (m.Value == " ")  
                      continue;  
                  if (double.TryParse(RemoveAcceptedChars(m.Value), out tmp))  
                      continue;  
                   string mTrim = m.Value.Trim();  
                   sb.Replace(m.Value, " " + LRM + mTrim + " " + RLM);  
              }  

              return RLE + sb.ToString() + PDF;  
          }  
          catch { return Text; }  
      }  
      private static string RemoveAcceptedChars(string p)  
      {  
          return p.Replace("+", "").Replace("-", "").Replace("*", "").Replace("/", "");  
      }  

Thank you for sharing your final solution with us, Nir. Would you mind making this ticket public so I can point other customers to your example? I'm sure many of them we'll find your workaround worth reviewing.

@Yaroslav, please provide the RTL suppprt in XtraReport.
I'm just evaluring to see if XtraReport can handle RTL text via some fix. The sole BIG problem of Devx is the lack of report rtl support.
I tried the non printing controls but it seems the XtraReport doesn't take them into action.
Please provide a working fix at least for the moment till you fix it completely
Thanks

Hi Ahmad,
I see you asked exactly the same question in the Mixed Arabic and Latin text in the DocumentViewer control ticket raised by you.  To avoid discussing multiple topics in this thread,  let's continue our conversation there.

Hii devex
 i hope this mail finds you well.

the years pass and still no solution for bidirectional text in report controls.
when can your customers expect this DECADES old issue solved?
your sugestion to add Directional chars cannot be fully applied becuase of the way you render the text.
i cannot evalute where the text is going to be wraped for example :
<nobr> some description of a functionalty in a big data ware house </nobr>
<br>
<nobr> is wraped in this strange method avoiding any workaround to work</nobr>
<br/>
<nobr>because if a ltr word or sentence is wraped between lines, this silly nobr  cannot be aligned correctly</nobr>

FIXIT

best regards