Re: Improper handling of some mime types

Re: Improper handling of some mime types

[Kai Großjohann]

Kurt Swanson <direct@reply.not.desired> writes:

> Some mime types are not displayed at all--nothing, not even a button.

To show buttons for multipart/alternative, hit `K b'.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Improper handling of some mime types

[Kai Großjohann]

Kurt Swanson <direct@reply.not.desired> writes:

> So you're saying I essentially have to hit `K b' in every single
> article I read just in case there's (by Gnus) hidden data, and then,
> if there is an html version, choose that, and the click all buttons,
> hoping one of them will do something useful for me?

> To me this is a *serious* error.  There are two mime parts in
> message-id: tQCa8.5559$qt6.469306@newsread2.prod.itd.earthlink.net in
> the alt.binaries.pictures.orchid newsgroup.  To put it simply, there
> is part 1a, 1b, and 2; i.e. there are two versions of part one (they
> share the same id code) and one part 2 (different id).  Part two
> should be recognized as separate (and equal?) and displayed,
> regardless of the user's choice of a or b for part 1.  The fact that
> part 2's very existence can only be seen (and then handled poorly)
> when part 1b is chosen can't be the desirable functionality here...
>
> Please go and check out this article yourself...

I can't do that, for I can't find a server hosting that group.
Sorry.  (I tried Google, did I do something wrong there?)

Whether Gnus is in error depends on the structure of the message.  It
could be like this (using pseudo-XML):

    <part type="multipart/alternative">
      <part type="text/plain"/>
      <part type="multipart/related">
        <part type="text/html"/>
        <part type="image/png"/>
      </part>
    </part>

It could also look like this:

    <part type="multipart/mixed">
      <part type="multipart/alternative">
        <part type="text/html"/>
        <part type="text/plain"/>
      </part>
      <part type="image/png"/>
    </part>

Your description sounds like the first variant, and then the Gnus
rendering would be correct.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: Improper handling of some mime types

[ShengHuo ZHU]

Kurt Swanson <direct@reply.not.desired> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> Kurt Swanson <direct@reply.not.desired> writes:
>
>>> Some mime types are not displayed at all--nothing, not even a button.
>
>> To show buttons for multipart/alternative, hit `K b'.
>
> Ok, if I do that I can choose between text and html versions.  The
> picture button doesn't show under text, so I have to choose html, and
> then the button simply shows up as
> "[cid:alonglineofgibberishnottellingmeevenwhatthisbuttontypeis]".  I
> can then click this button showing the picture.
>
> So you're saying I essentially have to hit `K b' in every single
> article I read just in case there's (by Gnus) hidden data, and then,
> if there is an html version, choose that, and the click all buttons,
> hoping one of them will do something useful for me?
>
> To me this is a *serious* error.  There are two mime parts in
> message-id: tQCa8.5559$qt6.469306@newsread2.prod.itd.earthlink.net in
> the alt.binaries.pictures.orchid newsgroup.  To put it simply, there
> is part 1a, 1b, and 2; i.e. there are two versions of part one (they
> share the same id code) and one part 2 (different id).  Part two
> should be recognized as separate (and equal?) and displayed,
> regardless of the user's choice of a or b for part 1.  The fact that
> part 2's very existence can only be seen (and then handled poorly)
> when part 1b is chosen can't be the desirable functionality here...

You can customize gnus-mime-display-multipart-as-mixed,
gnus-mime-display-multipart-alternative-as-mixed or
gnus-mime-display-multipart-related-as-mixed to get a desired behavior
(some of them are new in oGnus).

ShengHuo

Re: Improper handling of some mime types

[David S. Goldberg]

(setq gnus-buttonized-mime-types (cons "multipart/alternative"
                                       gnus-buttonized-mime-types))

At least guarantees you the button.  However, you must have taken some
effort to see the text/plain instead of the text/html.  You must have
something similar to this

(setq mm-discouraged-alternatives (list "multipart/related"
					"text/html" "text/richtext"))


in your configuration somewhere.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Improper handling of some mime types

[David S. Goldberg]

>>>>> On 14 Feb 2002 08:57:09 -0800, Kurt Swanson
>>>>> <direct@reply.not.desired> said: 

> To me this is a *serious* error.  There are two mime parts in
> message-id: tQCa8.5559$qt6.469306@newsread2.prod.itd.earthlink.net in
> the alt.binaries.pictures.orchid newsgroup.  

I can't see any binary groups from where I am now, but I'll speculate
since I've seen this type of structure enough times that I bet it's
what's actually in that article.  What you're seeing is a structure
like this

1: Multipart/alternative
        a) text/plain
        b) multipart/related
           i) text/html
           ii) image/somethingorother

thus the image is actually associated with part 1b, not another part
separate from the multipart/alternative.  In general images don't
relate to text/plain; the nominal purpose of multipart/alternative is
to allow a message to do something "reasonable" on both rich and poor
displays.  I agree it's annoying since depending on your Emacs
version, gnus can display an image along with text/plain, but I
believe it is correct behavior for the MIME parser.  This is why I add
multipart/alternative to gnus-buttonized-mime-types.
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Improper handling of some mime types

[Karl Kleinpaste]

(setq gnus-unbuttonized-mime-types nil)
This will always show you buttons, wherever buttons are possible.

(setq gnus-mime-display-multipart-related-as-mixed t	; bug workaround.
This will step around the (w3?) problem of multipart/related image
display.

Or, rather than using the second of these, just hit `C-d' on such a
message, and see how Gnus breaks the message up.

Re: Improper handling of some mime types

[ShengHuo ZHU]

Kurt Swanson <direct@reply.not.desired> writes:


[...]

>> Whether Gnus is in error depends on the structure of the message.  It
>> could be like this (using pseudo-XML):
>
>>     <part type="multipart/alternative">
>>       <part type="text/plain"/>
>>       <part type="multipart/related">
>>         <part type="text/html"/>
>>         <part type="image/png"/>
>>       </part>
>>     </part>
>
>> It could also look like this:
>
>>     <part type="multipart/mixed">
>>       <part type="multipart/alternative">
>>         <part type="text/html"/>
>>         <part type="text/plain"/>
>>       </part>
>>       <part type="image/png"/>
>>     </part>
>
>> Your description sounds like the first variant, and then the Gnus
>> rendering would be correct.
>
> I believe it's the latter...

It is

     <part type="multipart/related">
       <part type="multipart/alternative">
         <part type="text/plain"/>
         <part type="text/html"/>
       </part>
       <part type="image/jpeg"/>
    </part>

Gnus rendering is correct too.

ShengHuo

Re: Improper handling of some mime types

[Kai Großjohann]

Kurt Swanson <direct@reply.not.desired> writes:

> Yes, I agree, if the mime is constructed this way, the image shouldn't
> be seen with text/plain.  When I C-d the article I see:
>
>    [1274: Diana Kulaga        ] <* related> V. Rev. Masao Yamada
>    [  33: Diana Kulaga        ] <1.* alternative>
>    [   4: Diana Kulaga        ] <1.1 text>
>    [  16: Diana Kulaga        ] <1.2 html>
>    [1227: Diana Kulaga        ] <2 jpeg> "V.
>
> This, along with my cursory inspection of the raw file, lead me to
> believe that the jpeg is not associated solely with the html.  I may
> be wrong.  I was wrong once in my life before...

That's right, the image is not only associated with the html.  But
multipart/related means that the first part should refer to the other
parts.  The text/html variant of the first part actually does this,
via a hyperlink.

But the text/plain version of the first part does not refer to the
second part, so the second part is not displayed.

(Imagine you had two text/html variants, and one was missing the
<a>...</a> element.)

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)