This is done due to wrong column widths weights calculations.
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.
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.
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.
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.
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.
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.
When a source RadFixedDocument is merged to a target RadFixedDocument, the content of the source document is cleared.
This may cause either big distance between some glyphs, or overlapping glyphs.