> How will the console know when it has to write up to down, right to left
I would argue strongly that we do NOT want the console to do anything other than traditional VT100-style left-to-right text output. Bidi or quaddi output are best left to specialized applications, otherwise we introduce a huge mess by getting the terminal writing direction mode desynchronized with that the application believes to be in. Bidi and Quaddi work only if there is editor support, and if there is, then the editor can easily also implement the full cursor control at application level. Sure, bidi terminal support sort of works a bit with restrictions for trivial applications such as cat in confined demonstrations, but you can't neatly implement the full Unicode bidi semantics in classic terminal semantics (because terminals "think" in terms of cursor coordinates and not in terms of self-wraping paragraphs). I simply don't feel this is the way to go, and the fact that there has been an ECMA standard for multi-directional VT100-style terminals for over 10 years and there still does not exist even a *single* widely-used implementation or application for it suggests that I'm not completely alone with this view. If we really want a terminal concept that handles Unicode bidi nicely locally, the resulting terminal concept will look much more like a sort of word processor or HTML editor. In it, the application can still monitor, echo and intercept all keystrokes, but can also via some nifty new ESC-sequence protocol rewrite the document currently being displayed, preferably in a way such that a terminal put into echo mode will behave just like a document editor. Such a paragraph-mode terminal would have not just a notion of a current screen matrix and cursor position in it, it would also have a notion of a "current paragraph" in which the cursor is located, and which is constantly reformatted in the terminal as the content of the paragraph gets modified. It is certainly doable and might be an exciting project, but it would be *very* far away from the old tty/VT100 style terminal semantics and would require substantial modification to applications. (Libraries like readline would actually become much simpler, as most of the relevant functionality would be implemented then in the terminal, and the application would just read from the terminal the resulting paragraph when the cursor leaves the paragraph, etc. Applications could to a large degree become ignorant of details such as directional changes and ligature substitution, which would be done autonomously by the terminal.). The question is whether we want to have such a revolutionaly terminal concept for really full-featured support for "complex scripts". Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
