PDF's blank when printed from Chrome

7 posts, 0 answers
  1. Travis Cotton
    Travis Cotton avatar
    22 posts
    Member since:
    Sep 2009

    Posted 04 Jan 2018 Link to this post

    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.

  2. Yang Cui
    Yang Cui avatar
    5 posts
    Member since:
    Mar 2010

    Posted 08 Jan 2018 in reply to Travis Cotton Link to this post

    I've also had the same problem with Windows7(X86)+Chrom(32bit version).
  3. Yang Cui
    Yang Cui avatar
    5 posts
    Member since:
    Mar 2010

    Posted 08 Jan 2018 in reply to Travis Cotton Link to this post

    The Demo on telerik's official website has the same problem.
  4. Travis Cotton
    Travis Cotton avatar
    22 posts
    Member since:
    Sep 2009

    Posted 19 Jan 2018 Link to this post

    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.

  5. Yang Cui
    Yang Cui avatar
    5 posts
    Member since:
    Mar 2010

    Posted 01 Feb 2018 in reply to Travis Cotton Link to this post

    Thank you, I will try agein.
  6. Yang Cui
    Yang Cui avatar
    5 posts
    Member since:
    Mar 2010

    Posted 02 Feb 2018 in reply to Yang Cui Link to this post

    Thank you, I will try again.
  7. Todor
    Admin
    Todor avatar
    396 posts

    Posted 12 Feb 2018 Link to this post

    Hi,

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top