lkml.org 
[lkml]   [1998]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Comments on Microsoft Open Source documentA
On Mon, 9 Nov 1998, Theodore Y. Ts'o wrote:

> 4. Unicode makes a displaying problem non-issue (all characters are in
> one huge font) at the price of modifying all string-handling routines.
> That however includes complete incompatibility with existing charsets,
> and lack of language-labeling.
>
> The reality is that you have to odify all string-handling routines
> anyway, because of languages like Chinese where 8-bit characters simply
> aren't enough.

And it already was done without Unicode. And surprise in cases where
UTF-8 can be processed transparently as a byte stream, so can every
other charset.

> You also want to be able to handle multiple languages using different
> character sets inside one particular document,

First, in most of cases it's a strawman argument because such documents
(ones that don't fit into any existing charset, considering that English
is always can be used in all national standards) are extremely rare, and
linguists that actually use such documents in most of cases still need
something more complex than that.

Second, I consider language/charset labeling to be a real problem that
should be solved regardless of appearing often or rare in one document,
and not because of languages mixing in documents but because of the need
of better language labeling in general, and the case of mixed-language
document is an example that should be considered to produce the most
clean, convenient solution. Unicode is simple, but not convenient from the
language handling point of view.

> which is in fact
> *simpler* to do with Unicode, since it's all (as you put it) one
> gigantic font. If you don't do this, you end up needing to have magic
> character-set switching escape sequences (or MIME-style headers, or some
> other complex solution), and your string and display routines end up
> getting just as complex, if not more so.

I only claim that the problem is complex enough to require such a
complex solution -- simple one solves a tiny part of it, but cuts any way
back to labeling because the whole puprose of it is to remove all
labeling. With language labeling the purpose of Unicode is lost --
and of course, Unicode supporters never proposed any language labeling
or language-dependent processing for UTF-8 strings.

> The bottom line is that doing internationalization is hard.

Exactly my statement minus a part that "simple" solutions cause
enormous harm.

> As one I18N
> expert was heard to say, "It would be easier to teach them all English."

I see that phrase as umm... radicalized version of the decision
to use Unicode and UTF-8.

> Any solution will end up impacting some people more than others. It is
> no doubt true that UTF-8 may end up impacting certain people more than
> others. But the backwards compatibility aspects of UTF-8,

It's certainly backward compatible with ASCII (see above) and trivial
for iso8859-1.

> combined with
> the undeniable perponderence of where computers systems are deployed
> (i.e., U.S. and Europe) means that it was inevitable that UTF-8 would be
> chosen as the most pragmatic solution which impacts the smallest number
> of people and allows for the easist transition to a full I18N support.

Computers are produced in a lot of places and used everywhere. Pressure
of companies to standard committees is mostly applied in US and Europe
though.

> From where I sit, Microsoft wasn't the only company pushing Unicode; the
> push for Unicode and UTF-8 came from all directions, not just Microsoft.
> Or are you going to claim that the developers of Perl and X are pawns of
> Microsoft?

X did not adopt UTF-8, it uses multi-charset i18n support.

> Instead, it seems pretty clear that Perl and X chose UTF-8
> because

...IETF loudly declared UTF-8 to be The Only Standard, defined XML
UTF-8-only, and Larry Wall not being familiar with the issue was
misled into believing that UTF-8 indeed is the only standard that must be
supported instead of "legacy" charsets and their labeling.

> it's the sanest way to make the very hard transition from 8-bit
> characters to supporting internationalization, including character sets
> that simply won't fit in 256 character slots.

The nature of Perl and its data handling does not directly impose
restrictions of that kind.

> Finally, what in the world does this have to do with the Linux kernel?

Certainly it has to do with Linux kernel more than Microsoft
marketing/business strategy that is the main topic of this thread. Linux
kernel has some rudimental Unicode support, and there were proposals to
use it as "the" standard for filesystems, and claims that ext2 is
"designed" to support UTF-8 while it merely can use UTF-8 filenames just
like any other sanely designed filesystem.

> Followups to /dev/null, please.

If you don't want to hear answers there is no point arguing.

--
Alex


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.097 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site