I found a cause plus solution/work-around which I hope someone else can make use of.
I compared the base64 encoded HTML in the MHT file with the directly generated HTML4.0 markup and found a unique recurring discrepancy. Each table cell class in the HTML4.0 report is defined something like this :
.a23c
{
padding-left: 2pt;
padding-top: 2pt;
padding-right: 2pt;
padding-bottom: 2pt;
border: 1pt solid Black;
background-color: #d3d3d3;
vertical-align: top;
text-align: center;
direction: ltr;
layout-flow: horizontal;
writing-mode: lr-tb;
}
However, when I look at the decoded html in the MHT file the classes in there have two extra properties - width and min-width, e.g.
.a23c
{
padding-left: 2pt;
padding-top: 2pt;
padding-right: 2pt;
padding-bottom: 2pt;
border: 1pt solid Black;
background-color: #d3d3d3;
vertical-align: top;
text-align: center;
direction: ltr;
layout-flow: horizontal;
writing-mode: lr-tb;
min-width: 28.05mm;
width: 28.05mm;
}
It seems that having these properties unset causes Outlook to squash the table cells down (possibly because its HTML parser defines 100% width as somewhere around the 80 column limit?).
So, knowing this, the work-around would seem clear : read in the generated the MHT file, decode the base64 encoded HTML in there and send that as the mail body. This actually seems to work, and with a minimum of code :
var decoded_text = new StringBuilder();
using (var reader = new StreamReader(mhtFile))
{
while (!reader.EndOfStream)
{
var line = reader.ReadLine();
if (line != "Content-Transfer-Encoding: base64") continue;
reader.ReadLine(); //chew up the blank line
while ((line = reader.ReadLine()) != String.Empty)
if (line != null)
decoded_text.Append(Encoding.UTF8.GetString(Convert.FromBase64String(line)));
break;
}
}
I'm not entirely convinced of the robustness of this code, but it seems to work well enough for the moment so I'm going to accept this as the answer. Would be happy to learn of better solutions if anyone more knowledgeable ever ends up reading this!