> From: Egmont Koblinger <egmont_at_gmail.com>
> Date: Tue, 5 Feb 2019 01:32:34 +0100
> Cc: unicode_at_unicode.org
>
> On the other hand, it's not unreasonable for higher level stuff (e.g.
> shell scripts, or tools like "zip") to use such control characters.
Yes, but most of them won't ever do that.
> > No, this simple case must work reasonably well with the application
> > _completely_ oblivious to the bidi aspects. If this can't work
> > reasonably well, I submit that the entire concept of having a
> > bidi-aware terminal emulator doesn't "hold water".
>
> There isn't a magic wand. I can't magically fix every BiDi stuff by
> changing the terminal emulator's source code.
I didn't say "magically fix", I said "work reasonably well". I think
it would be a mistake to demand that any alternative to the default
each-line-is-a-new-paragraph method must be perfect. It should be
enough if an alternative is better.
> What my specification essentially modifies is that with this
> specification, you at least will have a chance to get the mode right.
My experience is that this is an important feature to have, but it
will (maybe even should) be used rather rarely. In most cases you
will just have plain text.
Moreover, emitting the control sequences that set the mode is in
itself a complication, because if the terminal doesn't support them,
the result could be corrupted display. You will need methods of
detecting the support, and those detection methods usually involve
sending another control sequence to the terminal and waiting for
response, something that complicates applications and causes delays in
displaying output.
> In case of "zip", the creators of that software know exactly how the
> output should look like
Not necessarily true. The translations are normally prepared by
people who are experts only in translating messages, they don't
necessarily consider layout issues, because for that you'd need to
look at the code or even run the program, something translators are
unlikely to do.
> If you're about to internationalize your software, this layout is a
> pretty bad choice.
Tell me about that!
But the reality is that this is what you get, and IMO the solution for
displaying this on a terminal should work reasonably well with that.
> This kind of formatting also ignores that English is a pretty dense
> language, in other languages the strings tend to become longer.
Actually, some/many RTL scripts tend to produce shorter text, because
vowels are not written, and because many words have very short roots.
But this is a tangent.
Received on Tue Feb 05 2019 - 10:07:49 CST
This archive was generated by hypermail 2.2.0 : Tue Feb 05 2019 - 10:07:49 CST