#11: Provide right-to-left reading orientation mode |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Category: | Edit | SubCategory: | ||||||||
Status: | Open () | Priority: | Highly Desired | Difficulty: | Complex | Created: | jsimlo | |||
Comment from jsimlo on Sun, Mar 24, 2013, 20:00 (comment id #17) |
---|
Right-To-Left reading orientation. Used by Arabic and Hebrew languages, and languages using Arabic or Hebrew alphabet, such as Persian and Yiddish (except for their numbers). Urdu is also derived from Arabic and Persian language. Ancient Egyptian, Etruscan, Greek and the oldest Latin could be written in both directions.
Chinese and Japanese can be written right to left and from top to bottom as well. Korean language, on the other hand, is written from left to right.
|
Comment from jsimlo on Sun, Mar 24, 2013, 20:20 (comment id #18) |
RTL affects positions of rendered characters and their visual order on the screen. Although this is handled by windows API quite nicely if printing whole lines, RTL positioning calculations are necessary upon printing separate line parts:
"این نرمافزار برای ویرایش پروندهها""ی سیستمی در محیط اماس-داس مناسب بود"
"این نرمافزار برای ویرایش پروندهها" and "ی سیستمی در محیط اماس-داس مناسب بود"
(text source: http://fa.wikipedia.org/wiki/%D8%AF%D9%81%D8%AA%D8%B1%DA%86%D9%87_%DB%8C%D8%A7%D8%AF%D8%AF%D8%A7%D8%B4%D8%AA_%28%D9%88%DB%8C%D9%86%D8%AF%D9%88%D8%B2%29)
|
Comment from jsimlo on Sun, Mar 24, 2013, 20:41 (comment id #19) |
If RTL and LTR text is mixed together, selections which span between RTL and LTR get visually discontinuous and characters which are next to each other in data representation might end-up far away from each other. Character position lookups are therefore no longer binary-search-friendly.
Note: This issue affects classic LTR orientation as well. Once RTL and LTR text is mixed together, binary-search is no longer possible regardless the overall rendering orientation.
|
Comment from jsimlo on Sun, Mar 24, 2013, 20:55 (comment id #20) |
Current implementation is rather oblivious to any RTL specifics and oddities, although the system API renders text parts correctly. The result is rather funny, partially obtrusive and definitely not anticipated.
|