Rank 1
So I have several well established applications for which I have not made any recent changes to. All of these applications have reporting functionality built in and Im displaying the reports in a report viewer. All standard stuff nothing exceptional in the setup. Up until about 3 weeks ago you could, from the ReportViewer print a report in Chrome without issue. Now.....every thing I print is blank. I can open these same reports, exported as PDF's, in Edge, IE or Adobe Reader and print them without any problems at all.
Im going to include some code for one of the basic reports but as you can see...nothing special. I learned that Chrome has made some changes to the the PDF plugin support but I dont really understand how this affecting the printing of a report from the ReportViewer. My test report only has a label field on it for simplicity's sake. Im running the latest versions of the WebUI and the Reporting software. The report looks normal in print preview and even if I select Print using system dialog the results are the same.
Again these arent new reports and no code changes have been made to them in months. My guess is Chrome has done something or perhaps there is a new setting im not aware of in either Chrome or the ReportViewer. Ive also tried the "Keep Together=false" setting to no avail.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Test.aspx.cs" Inherits="Test" %>
<%@ Register TagPrefix="telerik" Assembly="Telerik.ReportViewer.WebForms" Namespace="Telerik.ReportViewer.WebForms" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Test</title>
<link href="//fonts.googleapis.com/css?family=Arial:400,300,600,700|Raleway:400,300,600,700|Archivo+Narrow:400,700" rel="stylesheet" />
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css" rel="stylesheet" />
<link href="//ajax.googleapis.com/ajax/libs/jqueryui/1.11.4/themes/smoothness/jquery-ui.css" rel="stylesheet" />
<link href="../styles/site.css" rel="stylesheet" />
</head>
<body>
<form id="form1" runat="server">
<div>
<telerik:ReportViewer ID="ReportViewer1" runat="server" ReportSource-IdentifierType="TypeReportSource" Width="850" Height="1000"></telerik:ReportViewer>
</div>
</form>
</body>
</html>
Code behind:
using System;
using Telerik.Reporting;
public partial class Test: System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
dynamic report1 = Activator.CreateInstance(System.Reflection.Assembly.Load("EMS").GetType("TestReport"), false);
InstanceReportSource rptSource = new InstanceReportSource();
rptSource.ReportDocument = report1;
this.ReportViewer1.ReportSource = rptSource;
}
}
I dont mind telling users export only then print using Adobe Reader or another browser but I really liked being able to print from the ReportViewer.
6 Answers, 1 is accepted
Rank 1
Rank 1
Rank 1
So I was able to isolate this issue finally with help of our systems engineer who handles printing here. I tested printing from my home printer and the printing was indeed successful.
Upon relaying that information to the engineer here he did some testing and found that reports printed using PCL drivers print successfully each and every time.
However postscript drivers when used from Chrome always fail unless the Postscript Pass Through setting is disabled.
I say always with Chrome because Firefox and Edge always seem to rely on Adobe for printing so this isnt an issue there.
To test this in your own environment change the Postscript Pass Through setting on the postscript printer driver from enabled to disabled and the printing should work. The engineer said that enabling this was deemed unnecessary 99% of the time and disabling this would according to the internet speed up printing. In cases where pass through might be advantageous would be with programs like Pagemaker where you might not want the printer to reinterpret the postscript file.
Tons of info on what pass through post script is if you are curious. Again this doesnt seem to be an issue for PCL drivers just postscript ones. Whether its related to chrome only I dont think so. But I wasnt able to determine if the browser was also a factor.
Rank 1
Rank 1
We tried to replicate the issue with all locally available physical printers. Unfortunately, we couldn't reproduce the described behavior.
Therefore we still cannot confirm the solution provided by Travis Cotton here.
This makes us think that the problem is related to specific printers and their postscript drivers.
However, the feedback from the customers that have experienced the problem is entirely positive, i.e. the solution seems to work for all of them.
I suggest our users to share in this forum the printers that experience the problem. The list might help other community members to find the solution easier.
We would start with the printers reported by our clients in their support tickets:
Toshiba Studio 2550c
Sharp MX5070
Regards,
Todor
Progress Telerik