MHTML Tablix Row Height Doesn't Honor CanGrow=False

  • Hi all, I have set up a few subscriptions for an SSRS 2014 report. The report is basically a one-page tablix, so nothing fancy.

    The problem I'm having is that even though every row (and every cell, I've checked) in the tablix has the CanGrow property set to false, when the report is emailed via the subscription the rows double in height. The font doesn't grow, and the data isn't large enough to warrant the growth, but even if the text did grow, I would expect that the CanGrow property would take precedence when being rendered.

    When I view the report in preview mode (Visual Studio 2013) or on the report server, the row heights look correct, it's only in the emails that they're too tall.

    The render format of the report is MHTML and the emails are received in Outlook 2013 (although this issue existed on Outlook 2010 and SSRS 2008).

    I know Outlook can sometimes render html in a weird way, but I'm hoping that there's something I can do to fix this. Any thoughts would be greatly appreciated!

  • Guess I am going to necro this post but did you ever find a solution to this?  I just started having this issue with outlook.

  • No, I was never able to resolve. Other projects came up and didn't have the time to continue investigating. I'd still be interested to know the resolution to this though.

  • aaron.richardson - Thursday, May 25, 2017 9:48 AM

    No, I was never able to resolve. Other projects came up and didn't have the time to continue investigating. I'd still be interested to know the resolution to this though.

    What reason do you have for needing MHTML output for these reports?   Could PDF be a viable alternative?

    Steve (aka sgmunson) 🙂 🙂 🙂
    Rent Servers for Income (picks and shovels strategy)

  • We used MHTML because there was a business requirement for the report to be embedded in the email versus an attachment the user would need to open. In the future though, I'm going to push back if users ask for subscriptions to be set up like this because it's too much of a pain to submit to Outlook's strange HTML rendering. Fortunately we aren't often asked for subscriptions like this. Thanks for the suggestion!

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply