Ken wrote:
> nmh (and MH) reverse the order of multipart/alternative parts
> internally, so they show up as the "best" content first. I was
> going to get rid of this implementation wart when the MIME code gets
> retooled.
Best-first has some appeal to me: I start at the top, see
text/html or s
Norm wrote:
> But that only works when there IS a text/plain part. If there isn't,
> mhshow soldiers on and pretends that there is one. That' not what I
> want.
"mhfixmsg -reformat" will add a text/plain part, as long as your
mhn.defaults, profile, etc., has an mhfixmsg-format-text/html
entry. m
Ralph wrote:
> Hi David,
>
> > Something else added it along the way. As Ken noted later,
> > it's not in the message in the raw mailing list archive.
>
> Yes, I think that's what I said. :-) I was wondering if that
> something was Chrome.
The line was added before it got to my inbox, so def
> as Anthony pointed out, the default is really ISO-8859-1, but everyone
> treats that as windows-1252 (until we get to HTML5, of course).
Everyone bar at least links(1). :-)
-html-assume-codepage
Use the given codepage when the webpage did not specify its
codepage. (default
>If I understand you, you are talking about a script that does
>an mhlist, to get the arguments to mhshow.
As Ralph and others have pointed out, it's hard to tell if the
text/plain content is useful until a dumb human looks at it. I was
talking about doing it by hand.
>As to mhshow's -type argu
>The RFCs that define MIME say that alternatives parts representing the
>same content, e.g. text/plain, text/rtf, and text/html, shall be in the
>email in order worst to best when judged by their ability to represent
>the content. This allows a user reading the email in an MUA that's not
>MIME-cap
>> Ken said the HTML default was Windows-1252; it seems surprising
>> Windows was ever a default. I thought it was ISO-8859-1
>
>Right, per RFC 2616 ยง3.4.1.
That was my bad; as Anthony pointed out, the default is really ISO-8859-1,
but everyone treats that as windows-1252 (until we get to HTML5,
Jerrad Pierce writes:
>>Further, it seems to me that it would not be hard to determine if
>>the text/plain and text/html parts are essentially identical.
>This is a more difficult problem than you imagine. You'd have to render
>the HTML, and then decide what "essentially identical" means. For many
jerrad wrote:
> >The RFCs that define MIME say that alternatives parts representing the
> >same content, e.g. text/plain, text/rtf, and text/html, shall be in the
> >email in order worst to best when judged by their ability to represent
> >the content. This allows a user reading the email in a
Hi Jerrad,
> > This allows a user reading the email in an MUA that's not
> > MIME-capabable to come across the simplest format first, e.g.
> > text/plain.
>
> That's the theory, but many senders use a text/plain part akin to "If
> you cannot read this, get a better MUA"
Agreed, but I was trying
Hi David,
> Something else added it along the way. As Ken noted later,
> it's not in the message in the raw mailing list archive.
Yes, I think that's what I said. :-) I was wondering if that something
was Chrome.
> > Ken said the HTML default was Windows-1252; it seems surprising
> > Windows
>The RFCs that define MIME say that alternatives parts representing the
>same content, e.g. text/plain, text/rtf, and text/html, shall be in the
>email in order worst to best when judged by their ability to represent
>the content. This allows a user reading the email in an MUA that's not
>MIME-cap
Hi Norm,
> How is it decided that text/html is a better format than text/plain?
The RFCs that define MIME say that alternatives parts representing the
same content, e.g. text/plain, text/rtf, and text/html, shall be in the
email in order worst to best when judged by their ability to represent
the
>Further, it seems to me that it would not be hard to determine if
>the text/plain and text/html parts are essentially identical.
This is a more difficult problem than you imagine. You'd have to render
the HTML, and then decide what "essentially identical" means. For many
it would be differences in
Ralph wrote:
> Ken's pointed out the wasn't in the original message; were you
> seeing that in Chrome's view of the source? It might add it based on
> the default it chose.
Something else added it along the way. As Ken noted later,
it's not in the message in the raw mailing list archive.
> K
(I'm splitting a thread)
Ken Hornstein writes:
>
> W we're actually following the recommendations of the RFCs
> here. To answer your question very shortly, yes, you can make it display
> the text/plain part with the -part or -type options to mhshow (I'm guessing
> it will be somethi
Ralph Corderoy writes:
> Hi David,
>
> Ken's pointed out the wasn't in the original message; were you
> seeing that in Chrome's view of the source? It might add it based on
> the default it chose. Ken said the HTML default was Windows-1252; it
> seems surprising Windows was ever a default. I
Hi David,
Ken's pointed out the wasn't in the original message; were you
seeing that in Chrome's view of the source? It might add it based on
the default it chose. Ken said the HTML default was Windows-1252; it
seems surprising Windows was ever a default. I thought it was
ISO-8859-1 up until
18 matches
Mail list logo
