Date: Tue, 19 Sep 1995 13:20:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: peter@taronga.com (Peter da Silva) Cc: hackers@freebsd.org Subject: Re: Policy on printf format specifiers? Message-ID: <199509192020.NAA10542@phaeton.artisoft.com> In-Reply-To: <199509191354.IAA29446@bonkers.taronga.com> from "Peter da Silva" at Sep 19, 95 08:54:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >I personally have a number of problems with the encoding ordering for > >ligatured languages, like Tamil, Devengari, Hebrew, Arabic, etc., since > >there is an implied inability to use fixed cell rendering technologies, > >like X. > > Why should the storage encoding and the display encoding and the internal > encoding be the same? You can have three encodings if you want. The "internal encoding" you refer to is called process encoding. The display encoding should not have to be the same. But the simple facts of the matter are that if it is not, then you must translate the lexical values before display. For X applications, this means hiding additional font loading and character adjacency multiplexing in each X application, or changing the way the X server renders strings (making it not-quite-X anymore). There's some nice sample code for a program called "xtamil" that renders Tamil text (Tamil is an Indic script) that show up these problems quite well. > The overhead is minimal, it's not like we're mandating display postscript. No, that's exactly what's being mandated. Taligent and Adobe have many ties, starting at the board of directors level. Even if display postscript isn't really beaing mandated a similar technology, best described as "anything but X", *is* being mandated. This because the increaded application complexity and involvement in rendering is simply unacceptable. Rendering of strings *is* seperated from application intervention (XDraw[Image]String[16]) as long as it is possible to use fixed cell rendering for the languages, ar (as in "xtamil") to use a range based decoupling of font glyph set index from character set index. > >Rendering the file length meaningless and requiring the use of record > >oriented file systems with variant length records to handle data from > >fix length input fields from user interaction screens. > > And this claim is just weird. This is an application issue... file systems > have nothing to do with it. If the only things you feed into the kernel > are multibyte character strings, you don't need any of this. Suprise. Software engineers write applications. 8-). The complaint isn't that you can't work around what is effectively a loss of information, but that you have to do so. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509192020.NAA10542>