Printing in IE11 or OOB results in blank pages

[Ali]

When I try to print from the demo I have blank pages when using internet explorer 11 last version, same when the application is installed in Out Of Browser Mode.

Curiously printing is okay with FireFox 52.9 esr.

Tried many printers and even Microsoft PDF Printer.

OS Windows 10 x64 v1803

[Ali]

I missed an important precision : this occurs on windows with French locale and works fine on English windows...

[Peshito]

Hi Ali,

I tried reproducing the issue but to no avail. Could you share some more details about it? Is this reproducible only on your machine? Is there a way to test it on another one as well? Also, does it happen on all demos or a specific one? Did you use the document already loaded in the demo or a local one? 

Looking forward to your reply.

Regards,
Peshito
Progress Telerik

[Ali]

Thank you Peshito for your answer.

All the demos are having the same issue, PdfViewer and also RichTextBox.

Tests done with the default loaded documents in the demos.

Tested on 5 different windows 10s and 3 different Windows Servers 2016 all having French Windows version installed. Printing results on blank pages.

Tried to print to Microsoft PDF printer and have this results : First print, I was asked for the file name, it generates the pdf files, but all pages are blank. Second print : nothing happens, not asked for the file name, no error message.

Tested on a Windows Server with an English version of windows installed : All the scenarios prints the documents correctly.

[Peshito]

Hi Ali,

Thank you for your thorough research on this issue. I tried reproducing it on my local machine and on a virtual one following the steps you shared but to no avail. With RichTextBox and PdfViewer document's content is directly passed by the controls to the platform's printing mechanism and I am afraid I cannot suggest a workaround for this behavior. This mechanism relies on the proper implementation of the PostScript support in the printer drivers. That is why I would recommend to find suitable drivers. Sometimes checking if they are up to date and updating them solves such kind of issues.

Regards,
Peshito
Progress Telerik

[Ali]

Thank you Peshito for your answer.

But there are some other facts that let me think that the problem is elsewhere.

Printing from Firefox v52.9 works fine on all the machines that have the problem with IE and Oob. Waterfox and Palemoon (two other navigators that supports Silverlight) are also working in all the cases.

Switching a machine to English locale (both user and system account) makes the printing okay in IE and in Oob mode.

So, I don't think it is related to the printers drivers, because it is also reproducible with "Microsoft Print to PDF" virtual printer...

Thank you again for your help.

[Boby]

Hello Ali,

We are not able to consistently reproduce the issue, but our current assumption is that, when the culture is French, Silverlight generates PostScript which is incompatible with some PostScript supported by some printers (even virtual printers). What you can try as a workaround is changing the thread's cultures:

this.radRichTextBox.CommandExecuting += (sender, e) =>
{
    if (e.Command is PrintCommand)
    {
        System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
        System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US");
    }
};

this.radRichTextBox.CommandExecuted += (sender, e) =>
{
    if (e.Command is PrintCommand)
    {
        System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("fr-FR");
        System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("fr-FR");
    }
};

Regards,
Boby
Progress Telerik

[Ali]

Thank you Boby for your suggestion, but it didn't help.

I finally found a scenario that reproduces the issue (Windows 10 Pro Eng v1903 x64, IE 11.295.18362.0 upd 11.0.140) , here are the steps :

- Open PdfViewer FirstLook Example and save the default document somewhere (original.pdf)
- Print the document using "Microsoft Print to PDF" virtual printer and save it as test.pdf
- Check the test.pdf saved file, it should be ok using Acrobat Reader, (except that is printed as images...)
- Open the newly created file (test.pdf) in the FirstLook example, (it shows empty pages!...)
- Now open the original.pdf saved file and print it again using "Microsoft Print to PDF" printer
- the new file should now have 2Kb size and contains blank pages.

Hope this will help.

[Boby]

Hi Ali,

Thank you for the sample steps.

When the document is printed to PDF, the default Silverlight printing (which we use behind the scenes) sends the pages as PostScript pictures. In this case, the images for each page are rather large, e.g. 5000 x 5000 pixels. When the document with such images is loaded back, it causes random OutOfMemoryExceptions, which lead to the unexpected results of rendering and printing blank pages. 

Decoding image with similar size is challenging in Silverlight - we've implemented some optimizations for different platforms (e.g. WPF and WinForms PdfViewer-s) which directly render JPEG images with native OS code, but this was not applicable here.

You can detect that such exception is thrown using the OnException event. Another option could be to preprocess the document with RadPdfProcessing to detect such images and compress their size.

Regards,
Boby
Progress Telerik

[Ali]

Thank you again for your response Boby.

I understand that opening the document containing huge PostScript pictures may fail, but this is not the problem I'm pointing.

My problem is for the later use of the PdfViewer which will not print correctly after that step. It opens successfully a "normal" pdf, but when we try to print it, we have blank pages. It seems like the Silverlight printing processor is broken, and there's no way to restart or reset it. This occurs even with a new created PdfViewer instance, with RadRichTextBox and even with the Reporting Silverlight client...

[Boby]

Hi Ali,

According to our observations, after the first OutOfMemoryException the behavior of the operations requiring more memory (e.g. visualizing or printing big images) becomes unpredictable, and any call could cause another OutOfMemoryException if the GC doesn't manage to clear the unused memory fast enough. 

We have the PdfViewer: Implement mechanism to skip large images which would cause OutOfMemoryException if loaded request for consideration for the .NET Framework/.NET Core-based UI technologies (WPF and Windows Forms), but we do not consider implementing it for Silverlight, given the fate of the technology and the relatively low usage.

Regards,
Boby
Progress Telerik