- From: Tomer Mahlin via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Aug 2016 11:11:41 +0000
- To: public-annotation@w3.org
On modern OS (i.e. Windows, iOS, Android) text direction is associated with text rendering. In the storage both text with LTR or RTL or Auto text direction is represented the same way. Thus relating to text direction is best when it is done during rendering phase. Unicode control characters or UCC (RLE, LRE etc .... ) are very valid means for enforcing text direction at rendering time and https://www.w3.org/International/questions/qa-bidi-unicode-controls indeed includes a lot of good use cases / examples. However, using UCC for turning text direction into storage level property is cumbersome. For example: 1. This way we assume that all rendering engines which display text are fully UBA complaint. In reality this is not so. Moreover some rendering engines (Adobe Reader) might have quite different approach for Bidi (Arabic / Hebrew) text rendering. 2. Search / sort capabilities in ALL technology which allow rendering of Bidi text (i.e. web technologies, back end technologies etc.) should be altered to ignore UCC (when they are injected into text to convey text direction information) during search / sort 3. Editable contexts (mostly rich text editors ) use higher level protocols (i.e. HTML markup in web browsers) to convey text direction - very much similar to textDirection property discussed above. To support both higher level protocol and UCC we need to support extra mapping / conversion. 4. Many of higher level protocols (aka GUI SDK / toolkits) allow manipulation of text direction on the API level (instead of using UCC on the text level). Just a couple of examples: a. textDir is supported by all widgets in Dojo Toolkit b. setTextDirection function from Android -- GitHub Notification of comment by tomerm Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/336#issuecomment-238522821 using your GitHub account
Received on Tuesday, 9 August 2016 11:11:48 UTC