On 2011-05-18, Grant Edwards <[email protected]> wrote:
> Indeed it is. I run mutt using a shellscript that sets LANG and then
> runs a terminal:
>
> #!/bin/bash
> export LANG=en_US.utf8
> exec urxvt -T "mutt $1" -n "mutt $1" -ls -e mutt -F .muttrc.$1
>
>> and it still doesn't work, I'm at a bit of a loss...
>
> All the UTF tests I've run in mutt's terminal all seem to work fine.
>
> perl -CO -le 'print "\x{d4}"'
>
> Shows uppercase O-circumflex
>
> python3 -c 'print("\u7686\u3055\u3093\u3001\u3053\u3093\u306b\u3061\u306f")'
>
> shows the same (Kanji?) glyphs the web page I found shows.
>
> This file displays properly when I cat it out:
>
> http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
>
> All the languages are rendered properly, and even the braille and the
> cool graphical stuff at the bottom is OK.
[...]
> I just don't see how it could be a problem with the terminal or the
> font selection.
Ah ha! Things are actually quite a bit better than I thought. The
vast majority of e-mails are now displayed properly (including quite a
few with non-ASCII characters. Through dumb luck, the e-mail I
happened to be using to test the various iterations seems to be the
exception now. It looks like the problem has been narrowed down to
e-mails from one particular person.
A reasonable person would call it good enough and go one to something
else, but...
An example of what I think are the relevent but sanitized parts an
ill-displayed e-mail:
Received: from XX.XX.XX.XX ([XX.XX.XX.XX]) by Exchange.XXXXXXX.com
([XX.XX.XX.XX]) with Microsoft Exchange Server HTTP-DAV ;
Tue, 17 May 2011 15:56:08 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Content-type: multipart/alternative;
boundary="B_3388474568_4536735"
--B_3388474568_4536735
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
that=B9s pretty simple
doesn=B9t it?
delimiter (e.g. =8C.=B9) between
--=20
XXXXXX XXXXXXX =8B XXXXXXXXX XXXXXXX =8B XXXXXXX XXXXXXXXX
The single-quote characters denoted by =8C and =B9 don't display
properly. Neither does what I'm guessing is some sort of dash encoded
by =8B.
Those codes aren't right for ISO-8859-[1,15] or any of the common
Windows code-pages. Emails from that same Exchange server who use
Outlook seem fine, so it looks like it's a problem with Microsoft
Entourage.
Letting mutt display the text/html alternate via w3m works fine, so a
hook that did that would be OK, but I find that for most other e-mails
the text/plain version works better, so I don't want to tell mutt to
prever text/html over text/plain globally.
--
Grant Edwards grant.b.edwards Yow! Here I am in the
at POSTERIOR OLFACTORY LOBULE
gmail.com but I don't see CARL SAGAN
anywhere!!
