On Tue, 12 Feb 2002, Markus Kuhn wrote: > Tzafrir Cohen wrote on 2002-02-12 16:36 UTC: > > Too late. Hebrew (And I figure that arabic) is already used for filenames > > on windows, and many people got used to that. > > You might also have noted that Microsoft is working hard to eject the > DOS-stylecommand-line console completely from their windows > environment.
Windows had a very lousy "console" in 9x, a bit impoved in NT, and slightly improved in later versions. In any version of windows that supports bidi, the console supports bidi as well. Windows generally has a lousy command-lline interfacethat does not enourge you to work with the console too much. http://cygwin.com/ can be of great help in this field. > It's much easier to support bidi if you don't have to worry > about combining this with a terminal emulator. In a GUI, you get text > submitted as complete strings, over which you can then run the > reasonably simple Unicode bidi algorithm and then display the result > with a simple LTR renderer. In such a GUI API, bidi fits in as a simple > plug-in module. In a terminal emulator with a visible cursor and > real-time updating of the visible screen during editing as the text > arrives character by character, this gets far more complicated. > Just as it is not the job of the X server to do the bidi rendering, it is not the job of the terminal emulation to do the bidi rendering for full-screen applications. However, since virtually no full-screen application provides bidi support, the bidi conversion done by the terminal emulation is a good approximation. Sometimes it is good enough (and much better than no bidi) and sometimes it just complicates and messes things. Therefore this is a chice that has to be left to the end user. > I think it might be a good idea to really keep bidi completely out of > xterm. If people want to play around with bidi terminal semantics, then > I would suggest that they build a filter that can be plugged in between > the LTR terminal and the application, just like Juliusz' "luit" does > already for non-UTF-8 encodings. How can I disable bidi support at run-time with such a model? As I sterssed before, I heavily use this ability. On windows terminal emulations the only way I can disable bidi support is by setting the font to a font like "webmono" (shows some ISO-8859-1 chars as hebrew glyphs. The OS thinks this is latin, and does not apply bidi. A horrible hack). There must be an easy way for both the user and the software to disable this support. It wouldn't bothred me if under the hood xterm would invoke another process to do the job. > > > I have heard of various such attempts. None has managed to get any decent > > ammount of support. There exists simply too much litreture in > > right-to-left hebrew and arabic. > > Romanization was a huge and tedious job before texts were electronic. > Today, it is just another filtering step in the displaying pipeline. What you cannot automate, however, is the people reading those texts. It is also impossible to reprint all the existing texts (consider that the bible will have to written in original hebrew, for instance). As I said: you are not the first to suggest this. -- Tzafrir Cohen /"\ mailto:[EMAIL PROTECTED] \ / ASCII Ribbon Campaign Taub 229, 972-4-829-3942, X Against HTML Mail http://www.technion.ac.il/~tzafrir / \ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
