>On Tue, 2003-01-14 at 21:50, [EMAIL PROTECTED] wrote:
>
>> And? A POSIX filename is not a string of characters, it's a string
>> of bytes. You have no technical need to differentiate between the
>> two.
>
>If you do any sort of character-oriented manipulation on those names,
>you will.
Like what
>Moreover, say the system administrator does something like 'find
>/home'. The resulting stream will be a mixture of ISO-8859-X and BIG5,
>and impossible to reliably differentiate.
And? A POSIX filename is not a string of characters, it's a string
of bytes. You have no technical need to differ
>1) A multiuser machine, with users using different charsets.
> Who decides which one is "local"?
>
>2) The sysamin/user changes the charset, e.g. from iso-8859-1
> to iso-8859-15 to get the Euro character.
> How should the filenames stay in the local charset when
> this changes? Would the
>But what if the program *knows* the data is UTF-8 internally? Like all
>GNOME programs do, and my patch for dpkg tries to do?
Then it should be easy to convert it. You can't not convert and expect a
reasonable response - among other things, innocent UTF-8 characters can
include C1 bytes, and scr
asking here.
David Starner - [EMAIL PROTECTED]
([EMAIL PROTECTED] may be disappearing soon - [EMAIL PROTECTED] will work,
but is not suitable for high-volume traffic.)
d the like). Locale-dependent
GUI programs should probably do the same. GNOME and KDE may
save them as UTF-8, but that's questionable behavior; arguably, if you
want to use GNOME and KDE you should be using a UTF-8 locale, which
would solve the inconsistency.
David Starner - [EMAIL PROTECTE
ctate what
encoding end-users use; just what Debian packages use internally.
David Starner - [EMAIL PROTECTED]
([EMAIL PROTECTED] may be disappearing soon - [EMAIL PROTECTED] will work,
but is not suitable for high-volume traffic.)
#x27;s not broken.
> We can support non-UTF-8 terminals - as Radovan pointed out, the tool
Then let's do that, and not consign the rest of the world to the junk bin.
But we do do that -- we have filterm in the distribution. A filter between
the terminal
and the system is the easies
ns and
a large part of the rest of the world; it's likely to be useless to the
Japanese and
Chinese as well.
We can support non-UTF-8 terminals - as Radovan pointed out, the tool
is filterm. If you want to support an older terminal, that's
the easiest place to do so; you can't afford
ASCII, so for the most part Debian's
filenames won't be a problem. There is no way for a POSIX filesystem to tag
filenames with encodings, so there is no option for this to be a clean
changeover, especially as there's no clean state to start from.
David Starner - [EMAIL PROTECTED]
terminals.
--
David Starner - [EMAIL PROTECTED]
ges, and is the simpliest solution, IMO. Comments?
--
David Starner - [EMAIL PROTECTED], dvdeug/jabber.com (Jabber)
Pointless website: http://dvdeug.dhis.org
When the aliens come, when the deathrays hum, when the bombers bomb,
we'll still be freakin' friends. - "Freakin' Friends"
- Original Message -
From: Raul Miller <[EMAIL PROTECTED]>
Subject: Re: Bug#99933: Comments on Unicode
> On Fri, Jul 06, 2001 at 04:36:25AM +0100, David Starner wrote:
> > > Once unicode can act as a super set for every character set we
currently
> > > sup
Raul Miller <[EMAIL PROTECTED]>
> On Thu, Jul 05, 2001 at 06:55:24AM +0100, David Starner wrote:
> > I don't know where you got this impression, but it's wrong. Read the
> > document. It introduces a TAG START character, Ascii-equivelent tag
> > characters
n't save a user from)
or is reading a Chinese readme in a Japanese locale or vice versa. If this
is unreadable, the knowledgable user would know to switch fonts. At worst,
it's no worse than what we have now with having to change locales and fonts
to read a Chinese readme in a Japenese locales.
--
David Starner - [EMAIL PROTECTED], [EMAIL PROTECTED]
we could set up the locales for
libc and pick the languages package, as well as whatever else language
specific we need to do.
--
David Starner - [EMAIL PROTECTED]
http://dvdeug.dhis.org
"(You see, the best way to solve a problem is to rigorously define it in
terms of other people's probl
x27;t be a Perl script ever really an issue (especially
as it can launch Perl scripts)?
--
David Starner - [EMAIL PROTECTED]
http/ftp: dvdeug.net.dhis.org
It was starting to rain on the night that they cried forever,
It was blinding with snow on the night that they screamed goodbye.
- Dio, "Rock and Roll Children"
"Juergen A. Erhard" wrote:
> Chris> This is why *my* number one, absolute top priority for changes to
> the
> Chris> current menu system is to put in a TOP LEVEL ENTRY NAMED "Help".
> With
> Chris> at least: "Debian Online Help" (currently hidden in Apps/Tools),
> Gnome
> Chri
Darren Benham wrote:
>
> Obviously we can't remove gnome from the distribution. The only justifiable
> grounds to remove a *maintained* package is license! How about, we only allow
> one gnome library and any program that depends on earlier version have to be
> recompiled or broken...
First, Gn
19 matches
Mail list logo
