lkml.org 
[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: unicode (char as abstract data type)
On 21 Apr 1998, Matthias Urlichs wrote:

> Alex Belits <abelits@phobos.illtel.denver.co.us> writes:
> >
> > Don't put your words in my mouth. 8-bit charscters sets exist along with
> > multibyte ones, and both work. In the same applications, too. Unicode
> > "simplifies" that by creating one multibyte encoding that does *NOT*
> > provide features that any other encoding do, so regardless of having
>
> Yes it does. It provides _one_ encoding which doesn't depend on arbitrary
> context.

It provides one charset that is inferior to every charset it replaces
except iso8859-1. The dubious advantages of "label-less multilingual
plain text" isn't enough to justify that monstrosity.

> > Not really. It requires amount of resources, that with proper
> > standardization coule be enough for real internationalized software,
> > and _still_ solves nothing except "pretty foreign letters in a document"
> > problem.
> >
> It solves the "arbitrary letters in a document" problem. The decision of
> which font or which language or which whatever to use has been left out.

What font? There is more to language than font, and Unicode not only
ignores that, but makes impossible to recover that information after
conversion.

> IMHO, that's a Good Thing for the simple reason that there needs to be a
> migration path from _somewhere_ to UTF-8/Unicode/whatever. If they designed
> the thing with language/font/whatever in it, it'd be no longer compatible
> with ASCII. The Chinese would probably be pleased about that, but if nobody
> at all is going to use the standard you don't need one in the first place.

I have trouble parsing your statement ("they=?"), but most of software
is designed _not_ for any specific charset or font, but for stream of
bytes, treated in language-independent or language-dependent way. A lot of
software can handle any charset globally per document (if it cares) or can
be easily modified to accept multiple ones if they are labeled.

Most of language-related troubles are caused now by plain old sloppy
7-bit-only programming, that no Unicode or charset labeling or anything
but proper byte-value-transparent programming can fix anyway.

> Anyway, they also avoided the squabbles on what is or is not a separate
> language which would be unavoidable if they'd tackled that one.

If "they" are Unicode, they just demonstrated complete lack of any clue
in the matter and ignored a cornerstone issue of linguistics. Ignoring a
complex problem doesn't solve it and can only make it worse. On the other
hand, charset labeling allows for adding language definitions and, if
language support is designed flexibly enough, using external language
support modules when necessary. Again, it assumes that language
information is present somewhere, and the amount of processing necessary
for language handling makes kernel a wrong place to throw all such
processing it into there.

--
Alex


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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