On Fri, 13 Jul 2018 11:22:51 +0300 Eli Zaretskii via Unicode <unicode@unicode.org> wrote:
> > Different applications will have different needs here, so there's > definitely a need to provide applications and users with some control > of paragraph direction, and the way to do this is define high-level > protocols controlled by some optional variables. A well-known example > of that is the paragraph-direction buttons in Word and similar > processors (although they don't produce plain text, so the analogy is > limited). I have no argument with this, but I do think that in such cases it is wrong for the app to pretend that it is still treating the text as plain. If it is an email client, it should use a mime-type such as (just inventing something here) "text/plain:ltr" instead of "text/plain". Emacs should have an LTR-defaulting "Log mode" for log files, while keeping the UBA default for Text mode. With the current definitions and FAQ, plain text is simply not a viable option for intercahnge whenever BiDi is involved. The only upside I see for them is, essentially, what Eli and Richard noted: The possibility for improved performance in fringe use-cases. I repeat/rephrase my original question: The preference expressed by the Bidi FAQ, allowing programs to apply hifger-level protocols to plain-text with no limitation, affords performance improvements in fringe cases, for the price of giving up "Plain text must contain enough information to permit the text to be rendered legibly"[1] where BiDi is involved. Are there other upsides? And whether there are or not -- Does the trade-off reflect the intentions of the UTC? Do they realize how deeply BiDi plaintext is broken? Thanks for your attention and consideration, Shai. [1] http://www.unicode.org/versions/Unicode11.0.0/ch02.pdf page 19