Re: mailcap entry for image/jpeg not found

[James <jtp@xxxxxxxxx>]

Kyle, you rock!

Many thanks for your detailed and explanatory email. :)

-j

On Wed, Jun 10, 2009 at 3:49 PM, Kyle Wheeler<kyle-mutt@xxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Wednesday, June 10 at 03:17 PM, quoth James:
>> This is a weird one.
>
> :) Not as weird as you'd think, once you understand what's going on.
>
>> When I open an email that attached jpeg images, I get a "mailcap
>> entry for image/jpeg not found" message on the mutt status bar.
>
> In other words, what happened is that mutt tried to display the jpeg
> images INLINE (i.e. in the pager, as text). It probably did that
> because you added an "auto_view image/jpeg" or "auto_view image/*" (or
> something similar) to your muttrc.
>
> Here's what the muttrc man page has to say on the subject:
>
>     auto_view type[/subtype] [ ... ]
>     unauto_view type[/subtype] [ ... ]
>         This command permits you to specify that mutt should
>         automatically convert the given MIME types to text/plain when
>         displaying messages. For this to work, there must be a
>         mailcap(5) entry for the given MIME type with the
>         copiousoutput flag set. A subtype of "*" matches any subtype,
>         as does an empty subtype.
>
> Did you catch that? Mutt is looking for a mailcap entry with the
> "copiousoutput" flag. Why? Because mutt is attempting to display the
> attachment INLINE, and the only thing it knows how to display inline
> is some form of text. This is commonly used for things like doc files
> (which can be rendered to text with various utilities) and html files
> (which can be rendered to text with various utilities). The only way
> this could work with images is to use some libascii tool to convert
> the image to ascii-art.
>
>> Hitting 'v', and then 'enter' on one of the images, however,
>> successfully opens the jpeg image.
>
> Right, because then mutt isn't attempting to display the image inline,
> and has the freedom to use just about any relevant mailcap entry.
>
>> Thoughts? Clearly the mailcap entry is correct if I can open the
>> image after hitting 'v' and selecting the jpeg.
>
> Strictly speaking, that does *NOT* prove that the mailcap entry is
> correct, merely that the entry is functional. It may be working for
> reasons you don't understand (no disrespect intended).
>
> Put it this way: mailcap entries are more complicated than simply
> defining a command to use to view a given mime-type. Among other
> complex tricks, you can specify particular types of output. The
> "copiousoutput" flag, for example, means "this command produces its
> output as text on stdout".
>
> The reason that mailcap entries can specify what type of output they
> produce is that some situations require particular types of output.
> This is a key example: viewing attachments inline in mutt's pager
> requires a plain text version of the attachment, which means mutt will
> only accept mailcap entries with the "copiousoutput" flag (i.e. those
> that promise to provide text).
>
> Of course, you can *subvert* the idea in order to get those files
> displayed via `display` even though it's supposed to be displayed
> inline. But that requires writing a small script and using that as
> your mailcap entry.
>
> Does that make sense?
>
> ~Kyle
> - --
> The only way to oppose a bad idea is to replace it with a good idea.
>                                                           -- Jack Kemp
> -----BEGIN PGP SIGNATURE-----
> Comment: Thank you for using encryption!
>
> iQIcBAEBCAAGBQJKMA48AAoJECuveozR/AWemYsQAJvMey52+E9h5AvocokQkn4T
> M3C4NZasww8u8N5fsgXf1Br9gGTz+cDioUajQLVyVJghqNZw0Sk7AvpJU0CCs5Un
> 0MeP9MUkQyOoEV54y+dB28a0GPP0QJCzDBVYzKZ6o3B58SkLtSkBTFQDzJNagtKe
> 28T5uyOODha0S+2N4lrUqs4aY+Y6gYwOsXqvqlcANaPtrMRlaKeU4DIfzBYk33VJ
> xdj/0mb5p8Wk/fsFpQkuZWkk95zdGNUQuwENuiDybzaFlgQLn09VBE1JFOfoK1A+
> bi1sv/Y1qPCSulW7uXPo4SU4xocn+1lf6U9gWbw0LG8o/CcZw5eoYmQJXPL1Qtt/
> VSxmKQn66zuY4FbwaSJFAljsEg8X65VxVzxpbtM+iPwMwhnlS+LIba+c1J/L5Lv0
> fx5KDCTpv3RFRNzf58pl+nitGvImt6pkht+4DjcgnqOubOXlj8/XzTnJSmSaeD44
> f3l6E5kvIdSZZXRC4dEQoKbElFOfJ2pqDyr9rant4+3TMKmbA7UPPgCGAXbCH1mX
> Tk3MYhYOcTWxwwdsfr1ZZe3nfUpLW1oSx/JUIAuuz8PLwMQHYGHhqeWCBjBjXzmB
> u2T1KH9G4hC2DpGWU5pg3KhKoUImBVs41l1OCx9rcUbTmBAsVDq/au0EXBOkA6G/
> Ll0p6DTZ2QZchF8pvb1K
> =I4LX
> -----END PGP SIGNATURE-----