Re: [alreq] Realms in which display of Bidi data is not guided by UBA ( i.e. zOS, Adobe Reader)

@khaledhosny @shervinafshar thanks a lot for your comments. 
I think one of the key point to understand / clarify  is if as part of alreq you provide a general guidance for Arabic text layout (for example on a piece of paper, book, sand, water, piece of metal, stone or wood etc.) or the guidance is tailored to computer based world. Based on _".... This document describes requirements for the layout and presentation of text in languages that use the Arabic script when they are used by Web standards and technologies, such as HTML, CSS, Mobile Web, Digital Publications, and Unicode...."_  https://w3c.github.io/alreq/ I would presume that you target web technologies. This perception is also indirectly supported by the fact that UBA is mentioned in section 2.3 https://w3c.github.io/alreq/#h_direction

I also believe (please correct me if I am wrong) that the guidance provided in https://w3c.github.io/alreq/ is meant to target (in particular) the audience of software developers / product owners to assure their products address requirements associated with Arabic text layout. 

No doubt UBA is very widely spread standard leveraged by many ( I would even say overwhelming majority ) software product / platforms. As compared to it zOS terminals, Adobe Reader and text editor which decides to ignore UBA are in minority. I thus don't believe that a lot of attention should be dedicated in the guidance to edge cases like that. Having said that I do believe that it should be at least briefly mentioned that while UBA is widely spread standard, there are several cases in which it is not used for laying out text on the screen. For a reference please see this article: https://www.w3.org/International/questions/qa-visual-vs-logical 
If you still believe that none of such comments are appropriate please feel free to close this issue as irrelevant. 

Coming back to PDF / zOS for the sake of clarification only. As @khaledhosny mentioned, in PDF case 
the responsibility of text reordering is in the hands of text authors (PDF creators) rather than in the hands of text readers / viewers. This is exactly what happens with zOS terminals emulators. It is text author who should run UBA in his / her head (so to speak) and write it in already reordered form. It is very similar to how you write text on the paper. You reorder it in your head, move your hand to the expected spot above the paper and write down the letter using a pen. 

As opposed to this way, modern systems don't expect you run any reordering in your head. You simply type the text in the same order / way you pronounce it. The rest is done by UBA (employed by platform / application etc.). Namely UBA reorders this text before it is rendered on the display. 

Now, imagine you exchange text as-is between those two worlds. For example, you extract text from PDF (as-is), put it into HTML file (as-is) and upload the file to a web browser. Assuming text in PDF was correctly displayed in Acrobat Reader, it won't be properly displayed in web browser. This is since web browser assumes text is provided not reordered and will apply UBA on it in order to reorder it. However, text as-is extracted from PDF is already reordered. As a result text won't be displayed correctly in web since it was reordered twice (first time as part of text authoring during PDF content creation, second time when after being extracted from PDF it is rendered inside web browser).

-- 
GitHub Notification of comment by tomerm
Please view or discuss this issue at https://github.com/w3c/alreq/issues/119#issuecomment-303065137 using your GitHub account

Received on Monday, 22 May 2017 10:45:01 UTC