I cannot get a consistent rendering of the content within an HtmlTextBox from the WebReportViewer to Word and Excel exports
In HTML, the outer DIV height renders too short cropping the content.
In Word, one of the lines is not visible until you zoom in even though its the same as the next line
In Excel, the row is rendered to short and the bottom content is hidden.
Grabbing the rendered HTML from the WebForm ReportViewer it renders fine in Firefox, and Chrome but only appears to render correct in Internet Explorer when the Document Mode is set to Quirks or IE7, but this does not explain the Word and Excel issues.
The HtmlTextBox is set to 11pt because the Html Content is wrapped in a <font size=2> in order to target the desired height of 8pt.
Excel is rendering the content at 11pt as the HTML tags have been stripped, but the calculated size is not taken into account.
I assume that HTML do not like decimal font-sizes other then halves. IE 6.7pt => 6.5pt
In HTML, the outer DIV height renders too short cropping the content.
In Word, one of the lines is not visible until you zoom in even though its the same as the next line
In Excel, the row is rendered to short and the bottom content is hidden.
Grabbing the rendered HTML from the WebForm ReportViewer it renders fine in Firefox, and Chrome but only appears to render correct in Internet Explorer when the Document Mode is set to Quirks or IE7, but this does not explain the Word and Excel issues.
The HtmlTextBox is set to 11pt because the Html Content is wrapped in a <font size=2> in order to target the desired height of 8pt.
Excel is rendering the content at 11pt as the HTML tags have been stripped, but the calculated size is not taken into account.
I assume that HTML do not like decimal font-sizes other then halves. IE 6.7pt => 6.5pt
<div style='font-size:8pt; width:713px;'> <FONT size=2> <FONT size=1> I (We) certify that the information on this Balance Sheet is true and correct to the best of my (our) knowledge. I (We) have provided this information to xxxxxxxxxxx Bank to obtain or maintain a loan. I (We) understand that false statements made may be subject to prosecution. The xxxxxxxxxxx Bank is authorized to verify the statements contained herin and I (We) request and authorize all individuals or businesses to release information to xxxxxxxxxxx Bank regarding our business relationships. I (We) agree to all these conditions and terms of this application. <BR> <BR> <BR>Signature:________________________________________________________ Date: __________<BR> <BR> <BR> <BR>Signature: ________________________________________________________Date:__________ </FONT> </FONT></div><br/><hr/><br/><style type="text/css">div.htmlTextBox2 { line-height:110%; height:111px; top:535px; width:713px; font-family:Arial; font-size:11pt; margin:0; padding:0; }div.htmlTextBox2 * { line-height:110%; }.s67 { font-size: 9.79pt; padding: 0; }.s68 { font-size: 6.6pt; padding:0; }</style><div title="" class="htmlTextBox2 s64" style="overflow: visible; border:1px solid red;"><DIV style="MARGIN-TOP: 0px" class=html-root> <DIV class=s66 style='margin:0;padding:0;'> <FONT class=s67> <FONT class=s68> I (We) certify that the information on this Balance Sheet is true and correct to the best of my (our) knowledge. I (We) have provided this information to xxxxxxxxxxx Bank to obtain or </FONT> </FONT> <FONT class=s67> <FONT class=s68> maintain a loan. I (We) understand that false statements made may be subject to prosecution. The xxxxxxxxxxx Bank is authorized to verify the statements contained herin and I </FONT> </FONT> <FONT class=s67> <FONT class=s68> (We) request and authorize all individuals or businesses to release information to xxxxxxxxxxx Bank regarding our business relationships. I (We) agree to all these conditions and </FONT> </FONT> <FONT class=s67> <FONT class=s68> terms of this application. <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> Signature:________________________________________________________ Date: __________<BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> <BR> </FONT> </FONT> <FONT class=s67> <FONT class=s68> Signature: ________________________________________________________Date:__________ </FONT> </FONT> </DIV></DIV></DIV>3 Answers, 1 is accepted
0
Hello Steve,
At our side the provided HTML is rendered as expected in IE, Excel and Word.
Notice <hr /> tag is not supported by the HtmlTextBox item.
MS Word uses its own HTML rendering engine for HtmlTextBox items. Whereas fonts are preserved as set in the report definition. For more details, take a look at the Design Considerations for Word Rendering help article.
In Excel the whole HtmlTextBox content is rendered as a plain text without formatting. Also the CanGrow property will utilize the AutoFit feature of Excel, thus you may need to expand the cell to see the whole text. For more details, please check the Design Considerations for Excel Rendering help article.
Generally our suggestion is to divide the HTML into several items, and thus get a coherent result in Word and Excel. Also you can make IE to render in a certain standard mode by adding the following meta tag:
Since we cannot reproduce your issue with the cropped content, please open a support ticket and send us your report definition and some sample data to test it.
Regards,
Stef
Telerik
At our side the provided HTML is rendered as expected in IE, Excel and Word.
Notice <hr /> tag is not supported by the HtmlTextBox item.
MS Word uses its own HTML rendering engine for HtmlTextBox items. Whereas fonts are preserved as set in the report definition. For more details, take a look at the Design Considerations for Word Rendering help article.
In Excel the whole HtmlTextBox content is rendered as a plain text without formatting. Also the CanGrow property will utilize the AutoFit feature of Excel, thus you may need to expand the cell to see the whole text. For more details, please check the Design Considerations for Excel Rendering help article.
Generally our suggestion is to divide the HTML into several items, and thus get a coherent result in Word and Excel. Also you can make IE to render in a certain standard mode by adding the following meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />Regards,
Stef
Telerik
Have you tried the new visualization options in Telerik Reporting Q2 2013? You can get them from your account.
0
Steve
Top achievements
Rank 1
Rank 1
answered on 08 Jul 2013, 04:00 PM
The "<hr/>" tag was merely used separate the raw (source) Html markup from the HtmlTextBox rendered markup within the WebReportViewer.
Yes - Word is fine but I can't figure why some content would not be visible within word at 100% zoom.
Yes - Excel renders as plain text, but the HEIGHT of the cell is calculated from the Html RENDERED content and not the plain text content.
IE "<h1>This is very large text</h1>" should result in the Excel cell height being taller then the content, but my issue is that my HtmlTextBox FontSize is set to a larger font (11pt) to account for the relative font size calculation from our legacy content wrapped in <Font size=2> causing the Excel cell to render smaller then the plain text content regardless of the "CanGrow" property which only applies to setting the height equal to the calculated height and not "AUTO" as it would not be possible the the HTML Preview since everything is absolutely positioned. Changing the Excel cell's font size to 8pt results in the properly calculated height.
I'll check to see if <meta http-equiv="X-UA-Compatible" content="IE-7" /> will work but I'm not sure if this is supported from within IE8 but will do some testing.
I also believe the the Relative size calculations are fine in Word, but IE will not effectively rendered 6.78pt and will result in 6, 6.5 or 7pt.
This may only result from the nested font tag markup that messes up the desired font line height.
Open up the originally sent Html content in IE and play with the Document Mode.
<font size=2><font size=1>This font has non standard font line height that renders the same in FireFox, Chrome, but only IE7</font></font>
My long term goal will be to strip out the unfavorable font tags as it is an unsavory side effect of the WYSIWYG editor and not the real intent of the client.
Yes - Word is fine but I can't figure why some content would not be visible within word at 100% zoom.
Yes - Excel renders as plain text, but the HEIGHT of the cell is calculated from the Html RENDERED content and not the plain text content.
IE "<h1>This is very large text</h1>" should result in the Excel cell height being taller then the content, but my issue is that my HtmlTextBox FontSize is set to a larger font (11pt) to account for the relative font size calculation from our legacy content wrapped in <Font size=2> causing the Excel cell to render smaller then the plain text content regardless of the "CanGrow" property which only applies to setting the height equal to the calculated height and not "AUTO" as it would not be possible the the HTML Preview since everything is absolutely positioned. Changing the Excel cell's font size to 8pt results in the properly calculated height.
I'll check to see if <meta http-equiv="X-UA-Compatible" content="IE-7" /> will work but I'm not sure if this is supported from within IE8 but will do some testing.
I also believe the the Relative size calculations are fine in Word, but IE will not effectively rendered 6.78pt and will result in 6, 6.5 or 7pt.
This may only result from the nested font tag markup that messes up the desired font line height.
Open up the originally sent Html content in IE and play with the Document Mode.
<font size=2><font size=1>This font has non standard font line height that renders the same in FireFox, Chrome, but only IE7</font></font>
My long term goal will be to strip out the unfavorable font tags as it is an unsavory side effect of the WYSIWYG editor and not the real intent of the client.
0
Hi Steve,
Generally how browsers will round fractions depends on their layout engine:
If you need further help, please open a support ticket and send a runnable project illustrating the whole scenario. Any additional information as exported files would be helpful in investigating the issue further.
Regards,
Stef
Telerik
Generally how browsers will round fractions depends on their layout engine:
Thus the final rendered text may differ in browser. You can find more articles on the topic in msdn. In addition, we also recommend to replace font tags with CSS font-size. Notice that when you use the HtmlTextBox Edit Expression dialog, font tags are replaced by span tags with font-size CSS attributes.
As explained in the Design Considerations for Excel Rendering help article we are aiming to render the report as it is seen on screen. For different items are described their characteristics on exporting to Excel. In the case of the HtmlTextBox all formatting is stripped and thus is rendered just plain text in a cell with the size of the item on screen, so the report's layout remains the same.
If you need further help, please open a support ticket and send a runnable project illustrating the whole scenario. Any additional information as exported files would be helpful in investigating the issue further.
Regards,
Stef
Telerik
Have you tried the new visualization options in Telerik Reporting Q2 2013? You can get them from your account.