Due to the specifics of their implementation, both the Drawing library and the PDF Export implementations share certain limitations.
- General behavior
- Elements and styles
- Cross-origin resources
- Page breaking in elements
- Limitations and Browser Support
- The drawing of HTML elements provides no right-to-left (RTL) support.
- Exporting might not work when loading the page from a local file (
file://protocol) due to CORS restrictions.
- The PDF export of vertically aligned elements is not fully compatible with automatic page-breaking and might lead to undesired side effects.
- Browser zoom levels that are lower than 100% are not supported.
- The PDF v.1.5 specification limits the maximum document size to 5080mm x 5080mm (200 x 200 inches). As a result, larger files might not open in some viewers.
- The PDF export of the Shadow DOM is not supported.
- Complex letters (ligatures) are not supported and some of them are not rendered.
- The maximum file size of the exported PDF document has a system- and browser-specific limit—use a server-side solution for large documents.
- The content of the
<svg>elements is not processed. It will not be exported by the Drawing API.
- The rendering of
<select>elements is not precise and might lead to layout issues such as wrong padding or a missing drop-down arrow—instead of a plain
<select>element, use the Kendo UI DropDownList component.
- Of the border styles, the PDF export of
solidis only supported.
- The PDF export of
border-collapse:collapsetable style is not supported. To prevent double borders in the PDF output, avoid using adjacent borders for separate table cells.
- While the
radialCSS gradients are not exported in PDF,
- Elements with
position: fixedare not displayed in the output and are skipped over by the algorithm.
- Vertical texts which use the
vertical-lrvalues of the
writing-modeproperty are not exported.
- Overflowing text is clipped and
text-overflow: ellipsisis not supported.
<canvas>will be rendered as an image, but only if it is non-tainted, meaning if it does not display images from another domain.
- SVG referenced with the
<img>tag will not render in Internet Explorer, because IE taints the canvas.
- Only the export of images with correct extensions is supported. For example, a PNG image with a JPG extension that is displayed on a page might not show up in the exported PDF file or might cause exceptions in the PDF reader.
- Images without permissive Cross-Origin HTTP headers will not be rendered.
- Internet Explorer 9 is not be able to load images or fonts from another domain, and could raise an uncatchable security exception. If you need to support Internet Explorer 9, make sure to host images and fonts on the same domain as the application.
- Images will not be exported in IE if their source is an SVG document. These are considered to be tainted.
- Fonts and images hosted on different domains are exported/embedded only if the server provides permissive Cross-Origin HTTP headers.
- Internet Explorer 9 is not able to load images or fonts from another domain and might raise a security exception. If your application supports Internet Explorer 9, make sure that you host images and fonts on the same domain as the application.
<canvas>is rendered as an image only if it is not tainted—that is, only if it does not display images from another domain.
Page breaking happens only inside text nodes. Therefore, if an element has no text content, it cannot be split across pages. For example, an
<img> or a
<div>, which has perhaps a border or background image, but otherwise no content, is not split. If such elements fall on a page boundary, they are moved to the next page along with all the following DOM nodes. If they do not fit on a single page, they are truncated.
The following nodes do not support automatic page breaking:
* `<img>` * `<tr>` * `<iframe>` * `<svg>` * `<object>` * `<canvas>` * `<input>` * `<textarea>` * `<select>` * `<video>`
Positioned elements (
position: absolute) do not support automatic page breaking. Elements with the
position: fixed configuration are not supported at all. They will not show up in the output and are skipped over by the algorithm. For example, the input on an A4 page, which is demonstrated in the following example, will only display the Foo and the Baz paragraphs in the output file and the positioned
<div> element will appear on the first page at height 1000. Because this dimension is beyond the page boundary, the content will be clipped.
<p>Foo</p> <div style="position: absolute; top: 1000px">Bar</div> <p>Baz</p>
If the algorithm moves a node to the next page and even if the space to position it on the current page might be sufficient, all DOM nodes which follow it will be moved as well.
The following example demonstrates floating elements that acquire this behavior.
<p> some text before <img style="float: left" ... /> some text after </p>
This element might end up in a position where the whole text fits on the current page but the image is higher and would fall on the boundary. In this case, the image and a part of the following text will move to the next page.
- Internet Explorer 9 and later
- Latest Chrome, Firefox, Safari, and Blink-based Opera versions
Because of browser limitations and CORS-related security restrictions, PDF export is not supported for mobile—for example, locally stored font files cannot be loaded in hybrid applications. While in specific scenarios PDF export might still work on mobile devices, it is not supported by mobile browsers and hybrid applications.
Surface.create method uses feature detection to determine the default
surface type. Surfaces are listed in their order of preference. You can request a specific
type, such as
canvas, if desired. The preference will be ignored if no support is provided by the browser.