Last Updated: 12 Jan 2017 16:37 by ADMIN
Last Updated: 09 Dec 2016 14:55 by ADMIN
When images are added to the document with non-default quality (PdfExportSettings.ImageQuality different that ImageQuality.High) , they are re-encoded, which uses a lot of memory and may cause OutOfMemoryException for large images.
Workaround (works when inserting big JPEG images): In this case ImageQuality.High may be used and RadPdfProcessing will decode only the image headers to insert the image into the PDF file. As image pixels are not decoded with ImageQuality.High, there will be no OutOfMemoryException.
Last Updated: 18 Nov 2016 08:41 by ADMIN
This is happening when the pages in the document has content arrays similar to the following:

[34 0 R 243 0 R] [34 0 R 245 0 R] [34 0 R 247 0 R] ....

As you may notice the content stream 34 0 R is reused and the issue is caused by incorrect caching of content stream indirect objects by their reference.
Last Updated: 17 Oct 2016 17:25 by Carl
The issue is reproducible only with nested tables - tables positioned inside some other table cell. When using simple tables the text is always wrapped and rendered correctly. This may be used as a workaround for scenarios which allow replacing nested tables with simple ones.
Last Updated: 07 Oct 2016 05:29 by ADMIN
Currently this exception crashes the whole PDF document import. Instead we should simply skip the unsupported Action and import the rest of the PDF content correctly.
Last Updated: 22 Sep 2016 17:02 by ADMIN
For example exporting the text "\uD83D\uDE0A" with "Segoe UI Symbol" font family should export a single smiling face. Instead the characters are skipped during the export as PdfProcessing is trying to export them as separate char values ("\uD83D" and "\uDE0A") and the font does not contain glyphs corresponding to these char codes.
Last Updated: 23 Aug 2016 10:51 by ADMIN
When some character is not supported by the font, the fallback mechanism should try finding some other font that is capable of rendering the unsupported character. However, RadPdfProcessing fallback mechanism does not always find the correct font which sometimes result in wrong glyph visualization or in missing glyph.

Workaround: Font that supports these special characters may be used. This way the fallback mechanism will not be needed to export the PDF text.
Last Updated: 02 Jul 2016 21:05 by ADMIN
When a source RadFixedDocument is merged to a target RadFixedDocument, the content of the source document is cleared.
Last Updated: 18 May 2016 10:36 by ADMIN
This may cause either big distance between some glyphs, or overlapping glyphs.
1 2 3 4 5