alpine vs pine accents

[Antoine Jacoutot]

Hi.

Since I migrated from pine to alpine, I lost the accents.
In my .pinerc, I used to have the following:
character-set=ISO-8859-15

This does not seem to work anymore.

I tried playing with
display-character-set, keyboard-character-set
and posting-character-set but this doesn't help.

Note that I'm using alpine in screen and access my screen session
from several different terminals and OSes (via ssh), so I cannot really
use UTF-8.

Basically, accents appear like utf encoded characters (i.e. éa)) and it
is impossible for me to type accentuated characters.
Any idea how I could get the older pine behaviour?

Thanks.

[Andreas Prilop]

Post by Antoine Jacoutot
Since I migrated from pine to alpine, I lost the accents.
character-set=ISO-8859-15

First, get rid of "Content-Type: MULTIPART/MIXED":

[X] downgrade-multipart-to-text

Set your character-set variable to ISO-8859-1 and use
an ISO-8859-1 locale. What do you see here?

À A grave
à a grave
È E grave
è e grave
É E acute
é e acute
Ï I diaeresis
ï i diaeresis
Ç C cedille
ç c cedille

[Antoine Jacoutot]

Post by Andreas Prilop
[X] downgrade-multipart-to-text
Set your character-set variable to ISO-8859-1 and use
an ISO-8859-1 locale. What do you see here?

$ LC_ALL=en_US.ISO-8859-1 alpine

Post by Andreas Prilop
À A grave
à a grave
È E grave

...

:(

[Andreas Prilop]

Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed

Post by Andreas Prilop
À A grave
à a grave
È E grave

Your answer is completely meaningless because you only write
"this is what I see" but you do not describe it.

[Mark Crispin]

Post by Andreas Prilop
[X] downgrade-multipart-to-text

That is not good advice. It makes it more likely that the original
poster's email messages will be corrupted when they pass through his ISP's
mail server and/or a mailing list.

It is also irrelevant to the original poster's problem. At best, changing
this will make no difference; at worst, it will create new problems that
the original poster did not have.

It has been 15 years since the introduction of MIME. People should be
using MIME-compliant clients. There is no way to safely transport BASE64
or QUOTED-PRINTABLE content except within a multipart. The multipart
provides bounds for the encoded content that should have been, but were
not, part of BASE64 and/or QUOTED-PRINTABLE content. We now know today
that multipart should have been mandatory to use MIME at all.

The legitimate way to avoid the multipart is to set the option to enable
8-BIT ESMTP, which avoids the need to use BASE64 and/or QUOTED-PRINTABLE.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

[Andreas Prilop]

Post by Mark Crispin

Post by Andreas Prilop
[X] downgrade-multipart-to-text

That is not good advice.
It has been 15 years since the introduction of MIME.

I don't argue against MIME. I argue against unnessary usage of
multipart/mixed. By your arguments, there should be *no* messages
at all with
Content-Type: text/plain; charset=ISO-8859-1
since a single non-ASCII character should provoke multipart/mixed.

I wonder: Why does the possibility
Content-Type: text/plain; charset=ISO-8859-1
exists at all in the MIME standard?

[Mark Crispin]

Post by Andreas Prilop
By your arguments, there should be *no* messages
at all with
Content-Type: text/plain; charset=ISO-8859-1
since a single non-ASCII character should provoke multipart/mixed.

Not at all. I argue that there should not be a top-level header of

Content-Transfer-Encoding: BASE64
or
Content-Transfer-Encoding: QUOTED-PRINTABLE

That says nothing whatsoever about the Content-Type.

Post by Andreas Prilop
I wonder: Why does the possibility
Content-Type: text/plain; charset=ISO-8859-1
exists at all in the MIME standard?

Because of the possibility of

Content-Transfer-Encoding: 8BIT

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

[Andreas Prilop]

Post by Mark Crispin
I argue that there should not be a top-level header of
Content-Transfer-Encoding: BASE64
or
Content-Transfer-Encoding: QUOTED-PRINTABLE
That says nothing whatsoever about the Content-Type.

Post by Andreas Prilop
I wonder: Why does the possibility
Content-Type: text/plain; charset=ISO-8859-1
exists at all in the MIME standard?

Because of the possibility of
Content-Transfer-Encoding: 8BIT

Very well, then. In Pine, there are already different settings
for "8bit vs. QP" in e-mail and news. So you can send mail in QP
but news in 8bit. IMHO Quoted-Printable and multipart/mixed
are pointless and useless for news.

There should be separate settings of multipart/mixed for
e-mail and news; multipart/mixed should be off by default
for news.

[Mark Crispin]

Post by Andreas Prilop
IMHO Quoted-Printable and multipart/mixed
are pointless and useless for news.

Your opinion has been noted.

Post by Andreas Prilop
There should be separate settings of multipart/mixed for
e-mail and news; multipart/mixed should be off by default
for news.

QUOTED-PRINTABLE and BASE64 content in news is even more likely to be
damaged by little turlets put at the end of messages than the same content
in email.

Why don't you just use a MIME-competant newsreader? Aren't there more
important things in the world to worry about?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

[Helmut Richter]

Post by Mark Crispin
Why don't you just use a MIME-competant newsreader? Aren't there more
important things in the world to worry about?

The question is: Why don't you just force all potential readers of your
postings to use a MIME-competant newsreader?

[Nicolas KOWALSKI]

Post by Antoine Jacoutot
Hi.

Hello,

Post by Antoine Jacoutot
Since I migrated from pine to alpine, I lost the accents.
character-set=ISO-8859-15
This does not seem to work anymore.
I tried playing with
display-character-set, keyboard-character-set
and posting-character-set but this doesn't help.
Note that I'm using alpine in screen and access my screen session from
several different terminals and OSes (via ssh), so I cannot really use
UTF-8.

I have this in my ~/.screenrc:

defutf8 on


And my locale is set to:

LANG=en_US.UTF-8


This works perfectly with Alpine inside screen, with all the charset
options set to UTF-8.

Hope this helps,

[Rob van der Putten]

Hi there

Post by Nicolas KOWALSKI
defutf8 on
LANG=en_US.UTF-8
This works perfectly with Alpine inside screen, with all the charset
options set to UTF-8.
Hope this helps,

If you set everything to UTF-8 you can display any charset and any glyph
correctly.
UTF-8 is the way to go.


Regards,
Rob

[Andreas Prilop]

Post by Rob van der Putten
Avoid alphabet soup. Include the charset in your HTML header;
META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Your_Charset"

Hang a horseshoe over your doorway to defy superstition!

http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.1
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.2

[Rob van der Putten]

Hi there

Post by Andreas Prilop
Hang a horseshoe over your doorway to defy superstition!
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.1
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.2

The transport charset overrides the content charset;

sput:~$ lynx -head -dump
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.1
HTTP/1.0 200 OK
Date: Wed, 21 Nov 2007 22:00:32 GMT
Server: Apache/1.3.36 (Unix) mod_perl/1.25
Last-Modified: Mon, 30 Jul 2007 12:00:00 GMT
ETag: "c30a-547-46add2c0"
Accept-Ranges: bytes
Content-Length: 1351
Content-Type: text/html; charset=iso-8859-7
Age: 30
X-Cache: HIT from sput.int.sput.nl
X-Cache-Lookup: HIT from sput.int.sput.nl:8080
Proxy-Connection: close

The transport charset is usually not user configurable. If it isn't it
shouldn't be used.


Regards,
Rob

[Andreas Prilop]

Content-Type: text/plain; charset=UTF-8; format=flowed

See, you have a charset parameter in the header of your message
yourself.

The transport charset is usually not user configurable.

Even if this were true ( and it is not:
http://www.w3.org/International/O-HTTP-charset )
it is irrelevant. The content-type of a webpage and of a mail
message is defined in the header. Claiming that a user doesn't
know this, doesn't change things.

You don't claim that a writer/user cannot configure the charset
in the header of e-mail messages, do you?

[Rob van der Putten]

Hi there

Post by Andreas Prilop
See, you have a charset parameter in the header of your message
yourself.

This was about HTTP and HTML, not SMTP, NNTP or the contents of messages.
It depends on the particular config.

Post by Andreas Prilop
http://www.w3.org/International/O-HTTP-charset )
it is irrelevant. The content-type of a webpage and of a mail
message is defined in the header. Claiming that a user doesn't
know this, doesn't change things.

Knowledge != ability.

Post by Andreas Prilop
You don't claim that a writer/user cannot configure the charset
in the header of e-mail messages, do you?

Which isn't the point.
This is;

1) If the charset of a webserver is configured globally, there should
also be ways to override this charset. This has to be enabled in the
HTTPD config. It usually isn't; You have to explicitly enable cern meta
files or other means (AllowOverride FileInfo for .htaccess) of setting
the transport charset.
If this is not enabled the webserver should not have a default charset set.

2) You can't make assumptions about a clients default charset
(assumption is the mother of all fuckups). You therefore have to specify
the charset of your document. In the case of HTML that's the transport-,
content header or both. The advantage of the content header is that the
info is retained when the file is saved locally.

Of course, in some cases only setting the transport charset will do;
http://www.sput.nl/ucs-2.html
http://www.sput.nl/ucs-4.html


Regards,
Rob

[Antoine Jacoutot]

Post by Nicolas KOWALSKI
defutf8 on

Yes!
This is what I was missing...

The thing is my OS does not support locales really so.
Anyway, it works fine now.
Thanks!