On Sun, 18 Jun 2000 13:53:47 -0700
Earl Hood <ehood(_at_)hydra(_dot_)acs(_dot_)uci(_dot_)edu> wrote:
On June 17, 2000 at 11:14, J C Lawrence wrote:
When archiving a message which contains a multiplart/alternative
which contains a text/html and text/plain parts, what's the
configuration for MHonArc to pick the text/plain part and ignore
the text/html?
multiplart/alternative processing follows RFC guidelines.
Yeah, that's the problem. Exmh, my preferred MUA, ran into the same
problem, and in resolution allows the user to define a resource
which defines the preferred order of handling of parts:
*mime_alternative_prefs: text/plain text/richtext text/html
which says, given a a multiplart alternative, preferentially pick
the text/plain first, then text/richtext, then text/html. This
violates the RFC of course, but is also rather user friendly. I
know which one I prefer (given that not setting the resource gives
RFC conformant behaviour). ie The default is per the RFC, but you
can deviate if you wish and know what you are doing.
I don't know how well such a model would fit into MHonArc.
So for the case you have mentioned, if there is a a filter for
text/html, and it returns a non-empty string, then it will be used
over the text/plain portion.
Yeah, I figured that much, but I don't know perl well (hardly at
all, I'm a C/C++/Python chap). I've not had much success at hacking
a filter that's reliable (actually one that doesn't screw up more
than not).
To avoid this would require code changes. It may be possible to
modify readmail.pl to support enhancements to how
multiplart/alternative data is processed, bu I am unsure what kind
of resource interface would exist that hooks into what ever is
implemented.
Earlier I discussed having MHonArc generate PHP pages that supported
doing replies to archives messages from the web. I now have that
working. Sort of. One problem is such text/html messages which
just, well, quote poorly and in general are intractable. If I can
get this text/html business handled, plus a few other minor niggles
on message headers, I should be ready to roll this into public
production.
FYI the basic pattern is that MHonArc produces message pages which
consist of a series of variable assignments, assigning the header
field values to variables, the body of the message to a variable,
the various relative links, TSLICE etc to variables and so forth.
At the very end of the produced file it includes (PHP statement)
another PHP file from a known path which does the presentation layer
using PHPLib templates. In this way a simple edit to the template
file and all your archives instantly change appearance without
further work (nice while refining your look'n'feel).
--
J C Lawrence Home: claw(_at_)kanga(_dot_)nu
----------(*) Other: coder(_at_)kanga(_dot_)nu
--=| A man is as sane as he is dangerous to his environment |=--
