YAW x 3

[Trevor Smith]

On Wed, 05 Jul 2000 21:12:42 +0100 (BST), Simon Bowring wrote:

>[Yet Another Wish - actually 3 of them]

Actually Simon, I've already suggested something similar to the
powers that be. I like your addition of attaching a certain charset
to a user's entry in the address book though.

>1. User's charsets
>
>It'd be nice if we could configure a default charset encoding against
>individual users in the address-book, so that if their emails lack 
>charset="..." lines, then we could still say that "this guy" uses 
>ISO-Latin-1, and this other guy uses Latin-2, Win1252, CP850, CP437 
>or whatever.  The default should be US-ASCII (I think!)
>
>I've just been speaking to a swedish guy who is evaluating PMMail/2 
>("Ulf" for the benefit of Trever - I think he's been in touch).  He's 

Um... That's "Trevor" with an "o" thank you, and yes, Ulf was the one
that finally allowed me to understand the situation well enough to
articulate my suggestion for a new feature, which was this:

==================BEGIN FORWARDED MESSAGE==================
I have had a few complaints from European users who receive emails
from programs that fail/refuse to add proper Content-Type: and
Content-Transfer-Encoding: header lines.

The sending programs are almost certainly Windows programs (my guess)
and Hotmail has this problem too (surprise, surprise). Since they
refuse to add the standard headers indicating which charset is used,
regardless of whether they are using some standard Windows charset or
iso-8859-1 or whatever, of course PMMail/2 can not guess which was
used and can not display the message properly.

In one case the person actually asked his daughter to specifically
set Hotmail to use "iso-8859-1". She did and Hotmail still sent a
message with non-decipherable accented characters because, once
again, it refused to include Content-Type: and
Content-Transfer-Encoding: header lines.

I took the message she sent (he forwarded it to me), manually added
the appropriate header lines, and viewed it with PMMail/2 and boom!,
it appeared properly (of course).

Some facts:

1. This is the fault of the sending program.
2. There is no way PMMail/2 can ever guess which charset is used.
3. If PMMail/2 *could* somehow guess which charset was used, it could
display the message properly.

Because of these things, I propose that we add a drop-down list of
charsets to the "read message" window of PMMail.

When a message has proper headers to indicate the charset, that
charset would be automatically used and, presumably, displayed in the
drop-down list. Maybe it could be greyed out in the drop-down list so
the user could not change it.

When no proper headers were included, the "default" charset (which
could be set in the Account or General setup pages) would be
displayed/used. If this charset didn't do the trick, the user could
select one of the others from the list and the read message window
could be updated instantly.

This way the user could quickly find the right charset and overcome
this serious error which -- even though it is entirely the fault of
the sender's program, as far as I understand -- makes PMMail look
bad.
===================END FORWARDED MESSAGE===================

Just to let everyone know, my suggestions do not carry much, if any,
more weight that anyone else's so don't expect this new feature in
the next release. I think it will take some time to implement so...

Also, I'm not 100% sure that my experiences were translatable. I was
able to view one test message properly by adding the missing and
needed header lines but when I forwarded it, Ulf indicated he still
didn't see it properly. Probably there is more to this than I could
see.

>2. Support for the Win1252 charset (for encoding and decoding)

I hear that. I hate it, but I agree, we will need to support it. :-(

>3. MIME's in-line content disposition

Sure, sounds good to me. Also sounds stupid (why does the sender not
encode the entire message in the second charset?) but what the hell,
if Notes is doing it, we can either support it or wait for Notes to
disappear. (The latter strategy, however, will almost certainly just
see Notes replaced in the market with some even more bizarre, poorly
written and standards breaking product from Microsoft.)


-- 
 Trevor Smith          |          trevor@haligonian.com
 PGP public key available at: www.haligonian.com/trevor