Le jeu. 7 févr. 2019 à 19:38, Egmont Koblinger <egm...@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).