"EH" == Earl Hood <ehood(_at_)imagine(_dot_)convex(_dot_)com> writes:
EH> Yep, it's MIME. It is part RFC 1522. Currently, mhonarc does not
EH> support RFC 1522.
And I should know that. Oops.
EH> For now, there is probably no acceptible work-around for your needs
EH> besides limiting the From string length.
It's not a problem, really. I was just curious. I doubt that most
browsers could properly handle the embedded JIS anyway; Netscape can't
unless you also get rid of italics. Why it can't handle more than one base
font onscreen at once is beyond me.
EH> P.S. I am curious about your table-based index, and how it looks.
I wanted a display that lined up nicely that could show all of a long
subject. I came up with the following, which may include some local hacks
to MHonArc. Caveat hackor. An example can be seen at
<URL:http://www.hpc.uh.edu/fvwm/archive/9603/index.html>. The only real
problems I see is that large tables are somewhat slow for some browsers to
generate and I don't really know how to handle browsers that don't do
tables. Any ideas?
- J<
<IDXPGBEGIN>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>$IDXTITLE$ ($OUTDIR$)</title>
</head>
<body background=background.gif>
<h1>$IDXTITLE$ ($OUTDIR$)</h1>
</IDXPGBEGIN>
<LISTBEGIN>
<a href="$TIDXFNAME$">[Thread Index]</a>
<a href="..">[Top]</a>
<hr>
<address>
Last update: $LOCALDATE$<br>
$NUMOFMSG$ messages in chronological order<br>
</address>
<p>
<table>
<tr><th><strong>Subject</strong><hr>
<th><em>From</em><hr>
<th># of followups<hr>
</LISTBEGIN>
<LITEMPLATE>
<tr>
<td><strong>$SUBJECT$</strong>
<td><em>$FROMNAME$:30</em>
<td>$NUMFOLUP$
</LITEMPLATE>
<LISTEND>
</table>
<p>
<hr>
<a href="$TIDXFNAME$">[Thread Index]</a>
<a href="..">[Top]</a>
<p>
</LISTEND>