RE: Aging Dependencies?

Tcl uses UTF-8 internally for all character representations.  That started with Tcl 8.0

The best solution is to find a UTF-8 font, which will vary depending on your X11 configuration.  If you don't have a UTF-8 (Unicode) font, then it is possible to trick Tk into displaying the wrong character glyph.  I checked my fonts and I didn't seem to do anything fancy, however, I remember efforts many years ago to find a good UTF-8 font.  All I have in my exmh-defaults is:

!!! Font Resources
*font:  -*-courier-medium-r-*-*-18-180-*-*-*-*-*-*
*fl_font:       -*-courier-medium-r-*-*-18-180-*-*-*-*-*-*

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Wednesday, April 18, 2012 6:05 PM
To: Discussion list for EXMH users
Subject: Re: Aging Dependencies?

On Wed, 18 Apr 2012 18:13:04 -0400, Ken Hornstein said:

> Yeah, but I'm still trying to figure out what turned a particular 
> single-byte
> ISO-8859 character character into a 2-byte UTF-8 sequence.  It wasn't 
> nmh; was it Tcl?

I'm pretty sure it's Tcl code inside exmh, probably in mime.tcl  though I admit not fully understanding yet how it went astray.

> In the case you describe below, it seems like people should be "encouraged"
> to use a Unicode font and convert those headers to UTF-8 internally 
> irregardless of the user's locale.

It's certainly tempting to make the code "encourage" it :)

The biggest problem is that I run Fedora Rawhide on the laptop where I use exmh and as a result, I've usually got recent versions of everything.
But I'm sure we have exmh users on userspace old enough that their
utf-8 support is a tad lacking.

> Speaking of mojibake ... the part of the message where you quoted me 
> was interesting.  The character set was iso-8859-1, the encoding was 
> quoted-printable.  Unicode codepoints in my message that are valid in 
> ISO-8859 such as U+00E4 were properly encoded using quoted-printable.  
> But Unicode codepoints that were NOT valid in
> iso-8859-1 (U+201C, U+201D, U+FFFD) were simply spit out as UTF-8 
> bytes and NOT encoded properly via quoted-printable (which as I read 
> it is a violation of RFC 2045).  I don't know if that's how the email 
> left your SMTP server..

Well, the GPG signature was still valid, so it must have been already dorked when it left my laptop. ;)