Erik, 2008/8/23, Erik Trulsson <ertr1013_at_student.uu.se>: > > There are many applications that do not yet support UTF-8. > It would be bad if applications that just output 8-bit characters "as-is" > were broken. > If an application were to output characters from (e.g.) ISO-8859-1 and > syscons were to interpret them as UTF-8 it would not be pretty. > > I suspect it would actually break many current applications. > I agree that the proposed solution will have no effect on pure ASCII applications and would break apps that generate high bit characters of 8-bit encodings. My ideas on that are: 1) I mostly use FreeBSD in character mode with pure ASCII applications. For web browsing, writing e-mails and similar tasks I use X-based applications that have their own charset handling. 2) Adding the ability to map from an arbitrary 8-bit encoding (i.e. just keep the current features) is not hard. 3) Fixing the subset of applications that work in character mode and actually generate 8-bit characters is doable. Please note, that UTF-8 was specially designed for full interoperability with ASCII and partial with 8-bit encodings. For example, if we have an application that just performs a search for string of bytes in its input, it will work equally well if given iso-latin1 text and if given UTF-8 text. The real-life example is vi. Once I realized that kdm reads full user name as UTF-8 and that my FreeBSD is using koi8-r, I just took konsole, switched it to UTF-8, started vi and edited /etc/passwd as if it was UTF-8 (it actually was pure ASCII). And after that I am able to see correct russian names of users on my home PC in kdm window. So if someone thinks that many apps would be broken, let's name a few and I will test them using konsole and UTF-8. And again, how to check out the source, what is correct branch/tag? Should I check out from CVS or svn? To my mind, if I modify source code locally this certainly would not break applications on other FreeBSDs in the world. :-) Alexander ChuranovReceived on Sat Aug 23 2008 - 10:02:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC