The value of the TextBox is cut off in web report viewer

[Kishan]

Hi,
I have a report with a textbox which is serialized as follows 

this.textBox1.Location = new Telerik.Reporting.Drawing.PointU(Telerik.Reporting.Drawing.Unit.Inch(0.099999986588954926D), Telerik.Reporting.Drawing.Unit.Inch(0.30000019073486328D));
this.textBox1.Name = "textBox1";
this.textBox1.Size = new Telerik.Reporting.Drawing.SizeU(Telerik.Reporting.Drawing.Unit.Inch(5.4000000953674316D), Telerik.Reporting.Drawing.Unit.Inch(0.3999999463558197D));
this.textBox1.Style.Font.Name = "Verdana";
this.textBox1.Style.Font.Size = Telerik.Reporting.Drawing.Unit.Point(6.75D);
this.textBox1.Value = "Test01 test02 test03 test04 test05 test06 test07 test08 test09 test10 test11 test" +
    "12 test13 test14 test15 test16";

In the preview of Visual Studio designer value of the textbox is fully shown, but in the web report viewer the text is cut off after the 'test14' word. I have reproduced the situation with Q3 2013 in FireFox 26 and Chrome 31 (in the Internet Explorer 10 text is not cut off)
How to make the viewer to show whole text?

[Nasko]

Hello Kishan,

Thank you for the provided information. It allowed us to test and reproduce the issue locally.

This is a known issue logged in our system for improvement. What causes the cut off text is the differences in the way different browsers' layout engines interpret fonts and their sizes. 

In the meantime you can try changing the font and font size to work around the issue.

Regards,
Nasko
Telerik

[JR]

Has there been any update on this front?  We run into this issue constantly and have to use trial and error to find the bet font and size to resolve the issue.  We are running the latest version of the report viewer and engine.

[Stef]

Hi JR,

There are updates in the HTML rendering of reports. Still the same HTML and CSS can be interpreted differently depending on the browser's layout engine. It is recommended to use whole values for the font size and to test the selected fonts in browsers you need to support.
Always check for external CSS that can change the report's HTML by inspecting the rendered HTML on the page and teh style inheritance.

A new feature - private fonts - can help you use custom fonts without installation.

Regards,
Stef
Telerik by Progress

[JR]

Hi Stef,

 

Thanks for the reply.  I think this may be a symptom of another issue.  You see, we run the same report on our local machines and on our test sites and it doesn't cut off the text.  It's only on our production site.  I've checked the following and hope there is something else I might be missing:

- All have the same Telerik.Reporting.dll
- All have the same Telerik.ReportViewer.WebForms.dll
- All have the same report files (main and sub reports) 
- All utilize the same Stored Procedure
- All have the same ASPX page with the Telerik.ReportViewer control
- All have the same web.config settings

 

Help :-)

 

 

 

[Stef]

Hello JR,

Please inspect the rendered HTML and the applied styles by using F12 Developer Tools - Styles.

Check the HTML elements of the text that appears differently and the styles applying on those elements. If you detect a CSS file not related to the viewer, trace its source and test modifying the CSS selectors.


If you have a publicly visible link of the viewer in production and the viewer in a working environment, we can check the rendered HTML as well. Feel free to use a support ticket to share the links, if it is a private information.

Regards,
Stef
Telerik by Progress

[JR]

Hi Stef,

So, we could not find any outside influence on the CSS.  However,during trial and error, we copied the subreport used in the report from the server it was working to the server where it was not.  Now, both files had the same timedate stamp and using a diff comparison proved to have identical XML content.  Yet, after making the change, the report ran without issue.  I'm theorizing that the bad rendering was cached.  And the cache was invalidated when the datetime stamp of the file updated via the file copy.  Is that a likely hypothesis?  If yes, what are the cache configuration options you would recommend to avoid problems with poorly rendered reports in the future?

[JR]

Today the report stopped working again (although nothing changed).  We attempted to test the caching theory by updating the subreport file.  It did not make a difference.  I feel like we are back to square one.  Again, there is absolutely no reference to any external CSS.

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="ReportPreview.aspx.vb" Inherits="modules_6Reports_ReportPreview" %>

<%@ Register Assembly="Telerik.ReportViewer.WebForms, Version=10.2.16.1025, Culture=neutral, PublicKeyToken=a9d7983dfcc261be" Namespace="Telerik.ReportViewer.WebForms" TagPrefix="telerik" %>
<html id="html">
<head runat="server">
    
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <title></title>
    <style type="text/css">
        html#html, html, body#body, body, form#form1, div#content
        {
            height: 100%;
            margin: 0;
            padding: 0;
            border: none;
        }
    </style>
</head>
<body id="body">
    <form id="form1" runat="server">
    <div id="content">
    <telerik:ReportViewer ID="ReportViewer1" runat="server" Height="100%" Width="100%" ViewMode="PrintPreview"></telerik:ReportViewer>
    </div>
    </form>
</body>
</html>

[JR]

So, we've made an observation.  Changing the font size only masks the problem which seems to be when the first line of text bumps up against the right side of the textbox and then does not wrap.  By changing the font size, it changes the text so that a line break can occur and everything wraps correctly.  Changing the font size is not a valid solution because it may work for some data and not for other data.  It appears to be an issue with the calculation made in the rendering engine to determine where and if a line break should occur.  Please advise.

[Katia]

Hello JR,

As this behavior cannot be reproduced on our side we would appreciate if you send us a sample project that can demonstrate the issue in a support ticket so we can test it locally.


Regards,
Katia
Progress Telerik