Hi there,
I've been playing around with the grids built in pdf export functionality and am running into a few issues I was hoping that someone would point out for me.
I'm aware that there are issues noted on the page to do with this functionality, however the suggested solution to fix crashes in Chrome is to include the pako script
<script src=
"http://kendo.cdn.telerik.com/2015.2.805/js/pako_deflate.min.js"
></script>
Which I've done, but still the PDF fails to generate in Chrome. I have (I think) set up the grid correctly, as it works fine in other browsers
.DataSource(d => d
.Ajax()
.Read(read => read.Action(
"_Results_Read"
,
"Reports"
))
.ServerOperation(
true
)
.PageSize(20)
)
.ToolBar(tools =>
{
tools.Pdf();
tools.Excel();
})
//PDF removed for now until it is patched
.Pdf(pdf => pdf
.AllPages()
.FileName(
"AsbestosRegister.pdf"
)
.ProxyURL(Url.Action(
"_GridExportSave"
,
"Reports"
))
)
7 Answers, 1 is accepted

Apparently this posted early...
What I meant to add was, that I can see the network traffic making the individual requests to the read handler to get all the pages of data, but it just stops at the end and doesn't physically return the finished pdf to the user.
The dataset in question is about 1900 rows, but I've encountered problems with anything above about 1200. It works fine in Chrome with smaller data sets, but large ones fail.
Am I missing something obvious here as the code samples all suggest that to fix the issue of large datasets with Chrome, the only thing needed is to include that JS link
Thanks!
Matt
Hello Matt,
There is a certain limit of items that can be exported. It could vary depending on the browser, it's version, the operating system, so there is no specific number to be stated. The reason is that modern browsers do not provide support for streams. This means that we have to keep all data in memory until the file is generated. It's a limitation that we won't be able to overcome in the foreseeable feature. If exporting all of the items is required with this big data set, we do not recommend using the built in PDF export.
Regards,Dimiter Madjarov
Telerik

Thank you for your reply Dimiter,
Would I be correct in assuming that the inclusion of the pako deflate library as your site suggests to prevent crashing doesn't actually fix the issue then?
Is there the option of a PDF export without clientside streaming or processing as it seems that this is a fairly significant limitation which renders the functionality next to useless in its current state given that I'm hardly working with a large dataset
Thanks,
Matt
Hello Matt,
The pako JavaScript library helps with the compression of fonts and images, which allows reducing the output file size and using less browser memory. Nevertheless after a certain limit, exporting large data sets on the client side becomes impossible and is not recommended. In this case a 3rd party library should be used to export the content on the server side.
Regards,Dimiter Madjarov
Telerik

Dimiter
I too have a need to export large grouped data (20+ columns, 25000+ rosw ) to both PDF and Excel formats.
I read the limitations in this pose and in:
http://docs.telerik.com/kendo-ui/controls/data-management/grid/excel-export#server-side-processing
But in the above link there is mention of " For large data sets, it is highly recommended that you use the server-side solution the Document Processing Library provides. The RadSpreadStreamProcessing component is particularly suited for large data sets."
But I can find no examples that walk through setting up such a solution when the front end is AngularJS and the backend is C# WebAPI.
There is examples for WPF(Desktop ) solutions, which don't port at all and I cannot download from GIT
Can you supply me with an example( a link to ) that suits the WEB, please?
Hello Greg,
You could check the following project, which demonstrates a sample approach to implement Server side Excel export.
Regards,Dimiter Madjarov
Telerik by Progress

I have just resolved my problem with Export To PDF not working with Chrome. Using Network Traffic in Developer Tools I saw that there was a 404 error - DejaVuSans.ttf font not found. This did not stop Internet Explorer working - but it was the show stopper with Chrome. I moved the DejaVuSans font from the font folder to the Content folder (in with the calling css file), and changed the css code to (no path required now):
@font-face {
font-family
:
"DejaVu Sans"
;
src
:
url
(
"DejaVuSans.ttf"
)
format
(
"truetype"
);
}
Perhaps not ideal to have a font in the Content folder when there is a font folder in the root directory, but my app works now.