Re. multipart alternatives and text_type

Paul Haldane wrote:

> I've having trouble getting hypermail (2a18) to do exactly what I want
> with alternative text representations - if I've got a
> multipart/alternative message with one part text/plain and the other
> text/html I'd like to show one of those in-line and not show the other at
> all.

ok, I see a bug and a wrong usage here ;-)

> hm_ignore_types = text/x-vcard
> hm_ignore_types = application/x-msdownload application/ms-tnef
> hm_prefered_types = text/plain text/enriched text/html
> hm_text_types = text/plain text/enriched
> hm_inlinehtml = 0

This should make the html-part get shown. The "prefered_types" is of concern ONLY to the multipart/alternative parser. The parser will show the last part in the mail that fits one of those types. The MIME type multipart/alternative is defined to use a more and more advaned type further down in the mail so hypermail knows that the last prefered one is the most advanced and the one to use.

You should get the behaviour you wanted by removed text/html from the prefered types.

> ... I get the html saved as an attachment.

You should probably set inlinehtml to 1 to get it inlined. Or am I wrong?

> hm_ignore_types = text/x-vcard
> hm_ignore_types = application/x-msdownload application/ms-tnef
> hm_prefered_types = text/plain text/enriched text/html
> hm_text_types = text/plain text/enriched text/html
> hm_inlinehtml = 0
>
> ... I get the plain text and then the html, both in-line on the message
> page.

That is definitely wrong. This one should only use the last prefered type which is the html.

> (if I set hm_inlinehtml = 1) then the first one behaves like the second.

I think I may have destroyed the alternative-parser when I added the "text_types" stuff.

> Adding text/html to hm_ignore_types works but means that we discard all
> text/html types - not just alternatives, which isn't what I want.

No, that shouldn't be necessary.

> Is there a combination of the settings that will do what I want?

Not while this bug remains. :-( Received on Mon 12 Apr 1999 02:52:56 PM GMT