UAX #9: applicability of higher-level protocols to bidi plaintext

[Shai Berger via Unicode]

On Fri, 13 Jul 2018 11:22:51 +0300
Eli Zaretskii via Unicode <unicode at 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