Hello all,
I am struggling with the rendering of Web Archive (MHTML) into email.
In the report, the tables are sized correctly for display, but when
rendered as MHTML and placed into an Outlook message, the table widths
are tiny. It seems as though they default to about 4 inches, when in
the report they are actually around 8 inches.
When I look at the source of the MHTML, the individual cells (<td>
elements) are sized correctly. The sizes have been converted into mm
(8.125" to 206.38mm), but the containing table has no width property.
When viewed in a browser this doesn't present a problem. The
individual cell widths take priority and format the table. When copied
into an Outlook message, since the actual table elements don't have a
set width they shrink, and as a result the individual cells shrink
too.
I can manually edit the html source and assign the table elements the
right width, and it copies into Outlook fine. Just the way I want it.
Anyone come up with a way to get around this? Is there an additional
property in the RDL file I can set, or in Visual Studio to force the
width property into the table elements?
Thanks,
Jason
Jason - 29 Jul 2008 18:33 GMT
> Hello all,
>
[quoted text clipped - 23 lines]
> Thanks,
> Jason
Nevermind, I found a low tech solution. I added a textbox to the top
of the report containing an unbroken line of underscore characters.
After setting the right width (took some trial and error), I just set
the font to the same color as the background to be invisible.
With the continuous set of characters the report as a whole didn't
word wrap and shrink all the table elements as before.
I saw a couple of similar older posts about the same problem. Take the
solution for what it's worth.
- Jason
tideland - 30 Jul 2008 23:44 GMT
I'm experiencing this same problem and have identified this as a bug.
The problem exists within the source code of the Web Archive report which is
dynamically generated and transmitted via email.
Each Web Archive email contains an embedded style sheet where each class is
declared successively (.a1, .a2, .a3, .a4, etc.).
If you View Source from your email and examine the classes very carefully,
you'll notice that Reporting Services has dropped the "period" which should
precede each declared class.
Example: .a1, .a2, a3, a4, etc.). In this case, any of the objects which
reference classes a1 and a2 are fine but, any objects referencing a3 and a4
will have no formatting whatsoever because they're effectively misspelled.
That's the problem, it looks programmatic since the styles are direct
translations of the ones which are set in the Object Properties of the Report
Designer.
Most likely, there are a set of conditional or 'case' statements in the
source code of Reporting Services email generation library where the
Developer accidentally ommitted the necessary period, so when case = x the
periods are there, but when case = y they're missing and the class name is
wrong.
This needs to have a Bug Tracker assigned to it.
> Hello all,
>
[quoted text clipped - 23 lines]
> Thanks,
> Jason