Bidi paragraph direction in terminal emulators (was: Proposal for BiDi in terminal emulators)

[Philippe Verdy via Unicode]

Le jeu. 7 févr. 2019 à 19:38, Egmont Koblinger <egmont at gmail.com> a écrit :

> As you can see from previous discussions, there's a whole lot of
> confusion about the terminology.


And it was exactly the subject of my first message sent to this thread !
you probably missed it.


> Philippe, with all due respect, I have the feeling that you have some
> fundamental problems with my work (and I'm temped to ask back: have
> you read it at all?), but your message what your problem is just
> doesn't come across to me. Could you please avoid all those irrelevant
> stories with baud rate and font size and Asian scripts and whatnot,
> and clearly get to your point?
>

I have never said anything about your work because I don't know where you
spoke about it or where you made some proposals. I must have missed one of
your messages (did it reach this list?). So don't take that as a personal
attack because this only started on a reply I made (the one specifically
speaking about the various ambiguities of encoded newlines in terminal
protocols, which do not match the basic plain text definition (similar to
MIME) made only for static documents, but never tuned for interactive
bidirectional use (including for example text editors, which also requires
a modelization of 2D layout, and also sets some assumptions about
"characters" visible in a single cell of a regularly spaced grid, and a
known number of lines and columns, independant of the lines of the text
rendered and read on it.

Terminals are not displaying plain text, they create their own upper layer
protocol which requires and enforces the 2D layout (whereas Unicode is a
purely linear protocol with only relations between one character and the
next one in a 1D stream, and no assumption at all about their display
width, which cannot be monospaced in all scripts and are definitely not
encoded in logical order: try adding characters at end of a logical line,
with a Bidi text you do not just replace the content of one cell, you have
to scroll the content of surrounding cells and your input curet position
does not necessarily changes or you'l reach a point where a visual line
will be split in two part, but not at the rest position, and some parts
moved up to down

Bidi does not specify the 2D layout completely, it is purely 1D and speaks
about left and right direction and does not specify what happens when
contents do not fit on the visual line for the text which is already
present there before inserting new text or even what will be replaced if
you are in replace mode and not in insert mode: The Bidi algorithm is not
designed to handle overwrites, and not even the whole Unicoidce standard
itself, which is made as if all text was inserted only at end of lines and
not replacing anything.

For now terminal protocols, and emulators trying to implement them; that
must mix the desynchronized input and output (especially when they have to
do "local echo" of the input for performance reason over slow serial links
where there's no synchronization between the local buffer of the terminal
and the remote virtual buffer of the terminal emulator in the emitting app,
even those using the best "termcap" definitions) have no easy way to do
that. The logical encoding of Unicode does not play well and the time to
resynchronize the local and remote buffers is a limiting factor (over a
9.6kbps link, refreshing the whole screen takes too long, and this cannot
be done on every keystroke of input, or user input would have to be
dramatically slow if local echoing is also enabled, or most user inputs
that are too fast would have to be discarded, and this makes user input
very unreliable, requiring constant correction; these protocols are
definitely not human-friendly as they depend on strict timing which is not
the way humans enter text; this timing is also unpredicatable and very
variable over serial links and the protocols do not have any specification
for timing requirements. In fact time is constantly ignored, even if it
plays an evident role).

If you look at historic "terminal" protocols, technics were used to control
time: notably the XON/XOFF protocols, or mechanical constraints. Especially
when the output was a printer (with a daisywheel or matrix head). But time
was just control between one machine and another, a human could not really
interact asynchronously. And it was in a time where full-screen text
editors did not even exist (at most they were typing "on the flow" and text
layout was completely forgotten. This changed radiucally when the ouput
became a screen, with the assumption that the output was instantanous, but
the mechanical restrictions were removed.

Some older terminal protocols for mainframes notably were better than
today's VT-like protocols: you did not transmit just what would be
displayed, but you also described the screen area where user input is
allowed and the position of fields and navigation between them: the
terminal had then no difficulty to avoid breaking the output when entering
text with local eacho with good performance. But still it was impossible to
input Bidirectional text, only small separate unidirectional fields. We
were not concerned by the possibility of multiple scripts and Bidi inside
the input text, and Bidi on the ouput areas (where input was protected) was
possible using the visual ordering (and the 2D layout of the terminal,
which was also fixed, there was no resizable windows as of today; the input
grid size was static and determined by terminal initialization, or a menu
allowed selecting a new resolution, inform the remote application so that
they can handle it in their own virtual terminal and compute a lyaout that
could refresh correctly the user terminal, but this action was exceptional
and in fact slow over serial links; we were not working with today's tens
of megabits/s or more over virtual networking links).

Today these links are better used with real protocols made for 2D and
allowing an web application to mange the input with presentation layer
(HTML) and with javascript helpers (that avoid the roundtrip time). Even
the roundtrip is now much faster (typically around 30ms and transmission
time for the whole page is much lower than that, except for complex
contents having no or little user interaction (such as high resolution
images, or videos, rendered in a well delimited rectangular area, separated
from the user input areas, or just layered in transparence on top of output
area with a multilayered 3D layout).

But basic text terminals have never evolved and have lagged behind today's
need. Most of them were never tested for internationalization needs: not
just Bidi (Hebrew being simpler than Arabic...), but about sizing
constraints, notably Asian scripts (except CJK languages which are modeled
with characters occupying only 1 or 2 cells side by side and where
linebreaks cannot occur in the middle of a pair but can break anywhere
else, which is even simpler than for Latin with its complex breaking
rules!). The extension of CJK allowed the Latin-based terminals to evolve
in order to allow several discrete sizes, but still as an integter multiple
of fixed cells: this was possible only by adding a few attribute bits to
the cells to indicate if they display the whole character or the top or
bottom hald, or the left or right half (using the same technics of
attributes that were used to delimit input fields in input forms for
mainframes, something that was completely forgotten and remains forgotten
today with today's VT-* protocols, to indicate which side of the
communcation link controls the content of specific areas).

One solution would be to restore the attributes missing in VT-* protocols
and incite terminal emulators to supprot them. And then respecify precisly
the timing of events and when/how/where user input and output from input
can interact, when l:ocal echoing of input is allowed for reactivity, or
disabled (meaning that the user will have to wait for the response from the
remote side).

As well today's VT-* protocols have no possibility to be scriptable:
implemeint a way to transport fragments of javascripts would be fine. But a
modern terminal protocol should be more or less based now on HTML (the good
experiments are those found in the few existing web browsers for text
terminals: they are far superior to all existing legacy VT-* like
protocols, including the Windows command line terminal, or the X11
terminal, and all the many protocols found in the existing
"termcap"/"libterm" libraries on Unix/Linux systems for legacy displays
terminals and printer terminals).

Text-only terminals are now aging but no longer needed for user-friendly
interaction, they are used for technical needs where the only need is to be
able to render static documents without interactiving with it, except
scrolling it down, and only if they provide help in the user's language.
Printers also have abandoned these protocols (the last remnant was HPGL,
but it is no logner necessary, mechanical printers have almost died (except
for printing some payment tickets) replaced by inkjets and lasers (which
are much faster, less noisy too). They continue to fill a niche in an area
where people use very little natural text, but have to be able to view
documents that will be rendered much more easily and in a more
user-friendly way on rich-text protocols like HTML and 2D/3D layout engines.

Why not imagine a text -terminal with attributes deliminting a rectangular
area containing an object in which rich-text (HTML or other) will be
rendered and controled by the 2D/3D engine and left unmanaged internally by
the terminal protocols? Why these protocols do not allow more independant
"side" streams to control multiple objects (such protocol exists, e.g. in
X11, for example to transmit icons, or fonts, or control external areas
such as the content of a notification bar, or a menu, or a title bar)?

Old terminal protocols based on a single regular grid of equal cells are
definitely not user friendly and not suitable for all international text
(only a few scripts allow readable monospaced fonts). Today we need more
flexibility. But it will be difficult to readapt these old protocols to
support the necessary extensions and remain compatible with applications
still using them. We've made the transition for printers, but still not for
displays, and still not for other input devices than classical mechanical
keyboards, even if we all know now the GUI, resizable/movable/stackable
windows, mouse input, touch input on screens or pads, and many other kind
of sensors. I see liuttle way to adapt the old VT-like protocols (including
the DOS/Windows ANSI protocol).

In fact we still don't have any standard model for interactive applications
with multiple parallel data streams and interactions between them. Most of
these efforts have converged to HTML (and related meta-protocols focusing
on it for the final rendering such as XUL; there was an effort on
Postscript but it has stalled since long; GUI libraries are proliferating
after X11, win16, Win32, Swing...). May be it would be useless to try
filling the gap missing in legacy VT-like protocols (not worth the effort
when they continue to fill a niche whose usage is constantly decreasing).
But may be we could renew the efforts made in HTML over text-terminals (but
web browsers for them have lost most of their initial adopters: it's just
easier to create web services and use them from PCs or mobile devices). Web
APIs have largely taken the place, the rest is filled by propular desktop
of mobile OSes in their standard GUI, and otherwise by multimedia
audio/video codecs, OpenGL or similar, or the DirectX family on Windows and
extensions for X11 on Unix/Linux, plus common internationalization
frameworks for applications (and common databases like CLDR).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20190207/dbf3dd00/attachment.html>