[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII
From: |
Antonio Diaz Diaz |
Subject: |
Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII |
Date: |
Tue, 05 Mar 2019 01:34:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 |
Alfred M. Szmidt wrote:
My machine is over 10 years old. I can't even remeber when you
_couldn't_ modify the locale on a GNU system. If your system is that
old then you have more problems than viewing a text file! :-)
This machine is 20 years old. It is powered by a Slackware from 2007
because nothing more modern seems to be installable on it. Years ago I
tried to install on it the version of Slackware following the one it has
installed, but the desktop didn't start. There is possibly not even one
piece of software in this machine that supports UTF-8 properly. For
example, this is how maintain.info looks on an UTF-8 X terminal (Konsole
1.6.6 from KDE 3.5.7) viewed with info (GNU texinfo) 4.13:
-----------------------------------------------------------------------
This document uses the gender-neutral third-person pronouns “person”
(which can be shortened to “perse”), “per”, “pers” and “perself.�\
�� These
pronouns (aside from “perse”) were promoted, and perhaps invented, by
Marge Piercy in ‘Woman on the Edge of Time’. They are used just like
“she”, “her”, “hers” and “herself”, except that they apply rega\
rdless of
gender. For example, “Person placed per new program under the GNU GPL,
to maintain freedom for all users of per work, and this way perse knows
perse has done the right thing.”
-----------------------------------------------------------------------
Note that it even breaks a 3-byte double quote into 3 invalid UTF-8
characters. So, even if I "modify the locale", it still looks wrong.
But X is the easy part. The text console can't "modify the locale" to
UTF-8. Possibly I could compile a kernel with UTF-8 support in this
machine, but I do not want to do it because I use this machine to test
an old but perfectly working system. I know there are users out there
(not in the USA) with machines even less capable than this one. And in
fact I test some of my programs on even older hardware with older
software installed (80486 with Suse 6.3).
It sounds more and more like your situation is not the norm, but
rather a very special case.
In the first world, sure.
Why can you not simply convert (or regenerate) the relevant files?
Because it is inconvenient and could be easily fixed upstream.
Today, and for the last 10 years, UTF-8 has been the default and I
cannot think of any kind of terminal in the last 30 years that is
unable to display UTF-8 properly.
It is not (only) the terminal. It is the software. Given the lack of
concern for backwards compatibility among software developers, it seems
from very difficult to impossible to install UTF-8 capable software (or
anything else) in old machines.
IMHO, the problem is clear. Using multibyte UTF-8 characters where ASCII
suffices, inconveniences all users lacking an UTF-8 capable machine or
software.
Maybe we should have a poll, on how many 7-bit ASCII users there are
versus UTF-8? I don't see that the problem is clear at all. And I am
guessing that 7-bit terminals is not the norm at all.
Who said anything about 7-bit terminals? There are lots of
ASCII-compatible encodings that are not 7-bit ASCII.
Moreover, what is the advantage of multibyte UTF-8 quotes for users with
UTF-8 capable screens? They make the text easier to understand or something?
If we are talking about Info, then using UTF-8 produces a much nicer
output in X11 -- which is what the majority of users would be using
today.
http://www.gnu.org/prep/maintain/html_node/Web-Pages.html
"The overall goals are to support a wide variety of browsers, to focus
on information rather than visual adornments".
FWIW, I find the vertical ASCII quotes much nicer than those horrible
slanted multibyte UTF-8 quotes. IMHO, "much nicer output" does not
justify inconveniencing people until they throw away their old but
working machines, creating electronic waste in the process. For most
people most of the time UTF-8 is a waste of resources. I find
ISO-8859-15 superior to UTF-8 in every respect where both can be used
(English or Spanish texts, for example). Supporting a significant
fraction of Unicode is orders of magnitude more expensive than
supporting an 8-bit encoding, and is one of the causes why modern
software can't be installed (or runs horribly slow) on old machines,
forcing the premature obsolescence of perfectly working machines. I
consider the use of multibyte UTF-8 characters where ASCII (or
ISO-8859-1) suffices, the use of javascript or complicated CSS in web
pages, etc, as forms of planned obsolescence that should be avoided for
the good of society.
GNU always prided it self in moving forward, not backward.
I'm fine with moving forward, but I can't imagine in what way wasting
two bytes per quote is "moving forward".
Best regards,
Antonio.
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Antonio Diaz Diaz, 2019/03/01
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Alfred M. Szmidt, 2019/03/01
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Antonio Diaz Diaz, 2019/03/01
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Alfred M. Szmidt, 2019/03/02
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Mike Gerwitz, 2019/03/02
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Antonio Diaz Diaz, 2019/03/02
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Jose E. Marchesi, 2019/03/04
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Alfred M. Szmidt, 2019/03/04
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Jose E. Marchesi, 2019/03/04
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII,
Antonio Diaz Diaz <=
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Alfred M. Szmidt, 2019/03/05
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, John Darrington, 2019/03/05
- Re: [gnu.org #1363250] ASCII maintain.txt is no longer ASCII, Antonio Diaz Diaz, 2019/03/05