sorry, cat-typing sent that email a bit early. here's the rest:
for indic scripts and arabic having triple-cell ligatures is really indispensible for readable text. for east asian text a ttb, rtl columnar display mode is really, really nice. mongolian of course needs ttb, ltr columnar display. this may require contextual rotation of some paired glyphs (some of the rotated forms have unicode compatibility mappings, some don't.) yes, i realize unicode doesn't really handle vertical text yet, and the layout algorithms ar etheoretically slightly different — however mlterm does a passable job at least for CJK. how to handle single-cell vs. double-cell vs. triple-cell glyphs in vertical presentation is a tricky problem — short runs (<= 2 cells) should probably be displayed as horizontal inclusions, longer runs should probably be rotated. why don't we have escape sequences for switching between the DBCS and non-DBCS cell behaviors, and for rotating the terminal display for vertical text vs. horizontal text? Note that mixing vertical and horizontal is sometimes done in the typographic world but is probably not needed for terminal emulators (this requires a layout engine much more advanced than the unicode bidi algorithm, capable of laying out nested rectangular regions in all four mixed script directions, and presumably an escape sequence scheme that is nestable too akin to the bidi overrides and directional controls.) On 8/19/06, Ben Wiley Sittler <[EMAIL PROTECTED]> wrote:
for displaying doublebyte-charset documents the east asian width semantics are indispensible. there are very good reasons to have two modes for the terminal — east asian (all but ascii and explicitly narrow kana/hangeul/etc. as two cells) and non-east-asian (all but kanji/hanzi/hanja, hangeul, and kana single-width). the first is cell-compatible with the DBCS terminals (useful for viewing forms, character-cell art, webpages, etc., including e.g. doublewidth cyrillic characters used as graphics) and the second with non-DBCS terminals (actual cyrillic text, for example.) iuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuv c On 8/17/06, David Starner <[EMAIL PROTECTED]> wrote: > On 8/17/06, Rich Felker <[EMAIL PROTECTED]> wrote: > > This is nothing but glibc being idiotic. Yes it's _allowed_ to do this > > according to POSIX (POSIX makes no requirements about correspondence > > of the values returned to any other standard) but it's obviously > > incorrect for the width of À to be anything but 1, even if it was > > historically displayed wide (wtf?!) on some legacy CJK terminal types. > > It's not obviously incorrect; in a CJK terminal, everything but ASCII > was double-width, which actually a very convienant way of doing > things. Many of these fonts are still around, and I suspect that many > users still use terminals that expect everything but ASCII to be > double-width. glibc here is merely supporting the way things work. > > -- > Linux-UTF8: i18n of Linux on all levels > Archive: http://mail.nl.linux.org/linux-utf8/ > >
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
