The Grid PDF export is not showing the icons and it is rendering the wrong header in MVC Core(Bootstrap v4 and Default2).

The issue can be reproduced in our demo when the filtering is on and the paperSize is set to auto in order to show a bigger part of the Grid.
The allPages property does not seem to be working either.
The icons issue is most probably because you forgot to declare the WebComponentsIcons font. The PDF export demo contains this section:
<script>
/*
This demo renders the grid in "DejaVu Sans" font family, which is
declared in kendo.common.css. It also declares the paths to the
fonts below using <tt>kendo.pdf.defineFont</tt>, because the
stylesheet is hosted on a different domain.
*/
kendo.pdf.defineFont({
"DejaVu Sans" : "https://kendo.cdn.telerik.com/2016.2.607/styles/fonts/DejaVu/DejaVuSans.ttf",
"DejaVu Sans|Bold" : "https://kendo.cdn.telerik.com/2016.2.607/styles/fonts/DejaVu/DejaVuSans-Bold.ttf",
"DejaVu Sans|Bold|Italic" : "https://kendo.cdn.telerik.com/2016.2.607/styles/fonts/DejaVu/DejaVuSans-Oblique.ttf",
"DejaVu Sans|Italic" : "https://kendo.cdn.telerik.com/2016.2.607/styles/fonts/DejaVu/DejaVuSans-Oblique.ttf",
"WebComponentsIcons" : "https://kendo.cdn.telerik.com/2017.1.223/styles/fonts/glyphs/WebComponentsIcons.ttf"
});
</script>
Here's an example: http://dojo.telerik.com/egUWI/4
For allPages to work with such a big grid, do not forget to include Pako library to enable compression of the geerated PDF. (it works in the Dojo above, if a bit slow; the output has 83 pages).
The issue is only with the .NET MVC Core wrappers and only with the Bootstrap v4 and Default2 themes.
The Dojo with the jQuery version is working as expected.
Seems like a theme issue, see dojo.
Can't think of a failure mode with the wrappers that will affect the PDF Export.
Is there any movement on this?
@mishoo Please advise if the issue is related to the export logic or to the styles
@theOrlin If the issue is with the styles, could we look into it with bigger priority as it is observable in our live demos as well.
@simonssspirit the PDF library cannot find the icon font, that's the most likely reason.
@mishoo could we take a look at it as it is visible in the official demo?
The SASS theme only defines a WOFF font for icons (see here and here). However, the PDF library only supports TrueType (TTF) fonts. That's why the icons don't show up properly.
Unless there is some compelling benefit for using WOFF, I suggest the icon font to be converted to TTF. Alternatively, declare the TTF version in addition to WOFF, and the PDF lib should be able to find it.
An additional problem with the demo is that it's missing the DejaVu fonts. They don't seem to be declared in the SASS theme, so this style is pretty much useless: font-family: "DejaVu Sans", "Arial", sans-serif; (from the demo) — non-ASCII characters won't be displayed properly, for example:

@mishoo please notice in the screenshot in the first post the loading indicator is visible in the exported document when the paperSize is auto:

This is also observable in the Dojo with the latest version:
Please advise if a new issue is needed for this.
The reason for not including the ttf files and the DejaVu family in these themes is that the SASS-based themes use embedded assets, and embedding all ttf files will seriously bloat the shipped CSS. We embed the assets to make the theme easier to use when installing its package through NPM.
We could link DejaVu directly from the CDN -- this will resolve the issue at the price of a hardcoded link in the theme (declared through a SASS variable). This might not work for every customer (behind a corp firewall), but at least we won't break webpack configurations that do not have a ttf loader (like angular-cli generated projects).
As for the font icons, it seems the ttf file is about the same size as the woff file. Unless we hit problems with some browser-that-should-not-be-named, I guess we could use the ttf file instead. I have a vague feeling of dread that such a browser may complain about font loading because of some obscure security issue in a GDI font parser, but let's see.
@simonssspirit Indeed, that's a different issue. Please log separately and assign to me.
The icons in @progress/kendo-theme-default@dev now use a ttf font and the theme declares the DejaVu font family, however this does not seem to address the issues.
@mishoo could this be caused by the embedded font?
@mishoo have you had an opportunity to look into that? I'm a bit reluctant of shipping this in the themes, if it's not needed, and am currently holding the official releases.
The latest version of the Default v2 and Bootstrap v4 themes ship with TTF fonts, so this issue is resolved. If the theme CSS files is requested from a different domain, make sure that the file is loaded with the proper CORS header and the <link> element has a crossdomain="anonymous" attribute set.
Related: https://github.com/telerik/kendo-angular/issues/1317#issuecomment-385956724
@gyoshev what version of Bootstrap does the Boostrap v4 theme require? Bootstrap 4.0, 4.1, 4.1.x? Also when you say the latest version are you talking 2.13.4 or 2.14.x?
@progress/[email protected] includes the change. The theme does not require a specific Bootstrap version to function properly, but it has been tested most thoroughly with 4.0.
Most helpful comment
The reason for not including the
ttffiles and the DejaVu family in these themes is that the SASS-based themes use embedded assets, and embedding allttffiles will seriously bloat the shipped CSS. We embed the assets to make the theme easier to use when installing its package through NPM.We could link DejaVu directly from the CDN -- this will resolve the issue at the price of a hardcoded link in the theme (declared through a SASS variable). This might not work for every customer (behind a corp firewall), but at least we won't break webpack configurations that do not have a ttf loader (like angular-cli generated projects).
As for the font icons, it seems the
ttffile is about the same size as thewofffile. Unless we hit problems with some browser-that-should-not-be-named, I guess we could use thettffile instead. I have a vague feeling of dread that such a browser may complain about font loading because of some obscure security issue in a GDI font parser, but let's see.