CryptographicException is thrown when saving with PdfStreamWriter or importing with PdfFormatProvider.

The exception: System.Security.Cryptography.CryptographicException: 'The input data is not a complete block.'

According to the PDF specification:
A clipping path operator (W or W*) may appear after the last path construction operator and before the path-painting operator that terminates a path object.

Invalid:

W                          % clipping path operator
0 0 m                     % start of the path construction
596 0 l
596 842 l
0 842 l
h                            % end of the path construction
n                            % path-painting operator

0 0 m
596 0 l
596 842 l
0 842 l
h
W
n

Currently (in the invalid cases), the path construction is skipped on import.

This is the code for inserting the image: 

        static void Main(string[] args)
        {
            FixedExtensibilityManager.ImagePropertiesResolver = new ImagePropertiesResolver();

            //Telerik.Windows.Documents.Extensibility.JpegImageConverterBase defaultJpegImageConverter = new Telerik.Documents.ImageUtils.JpegImageConverter();
            //Telerik.Windows.Documents.Extensibility.FixedExtensibilityManager.JpegImageConverter = defaultJpegImageConverter;

            //Output("fyb-64.png", "output-working.pdf");
             Output("fyb.png", "output-broken.pdf");
        }
        private static void Output(string resourceName, string outputFileName)
        {
            var document = new RadFixedDocument();
            using (var editor = new RadFixedDocumentEditor(document))
            {
                Stream image = new FileStream(resourceName, FileMode.Open);

                var table = new Table
                {
                    LayoutType = TableLayoutType.FixedWidth,
                    Margin = new Thickness(10, 0, 0, 0),
                };

                var row = table.Rows.AddTableRow();
                var cell = row.Cells.AddTableCell();
                var block = cell.Blocks.AddBlock();
                block.InsertImage(image);
                editor.InsertTable(table);

                var pdfData = ExportToPdf(document);
                File.Delete(outputFileName);
                File.WriteAllBytes(outputFileName, pdfData);

                Process.Start(new ProcessStartInfo() { FileName = outputFileName, UseShellExecute = true });
            }
        }

        private static byte[] ExportToPdf(RadFixedDocument document)
        {
            byte[] pdfData;

            using (var ms = new MemoryStream())
            {
                var pdfFormatProvider = new PdfFormatProvider();
                pdfFormatProvider.Export(document, ms);
                pdfData = ms.ToArray();
            }

            return pdfData;
        }

Workaround: Instead of setting the ImagePropertiesResolver, set the JpegImageConverter: 

            Telerik.Windows.Documents.Extensibility.JpegImageConverterBase defaultJpegImageConverter = new Telerik.Documents.ImageUtils.JpegImageConverter();
            Telerik.Windows.Documents.Extensibility.FixedExtensibilityManager.JpegImageConverter = defaultJpegImageConverter;

When loading some PDF documents with German culture, part of the text got missing.

Workaround: set English culture before loading the document

Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");

Currently RadPdfProcessing allows setting standard fonts using FontsRepository static properties.

However, in RadWordsProcessing font can be set only by specifying FontFamily, FontWeight and FontStyle. As there is no way to set standard fonts this way, API users cannot benefit from using these fonts which may help them achieve smaller PDF size as standard fonts may not be embedded. The same applies to RadSpreadhProcessing as well.

Implemented import and export of IccBased, Indexed, Cmyk color spaces. Available in Q3 2015.

Available in R2 2018 Official Release version.

When characters are in the ranges 61472-61566, 61565-61695, 65535-65535 they are correctly exported with Wingdings font. However, when the character value is outside these ranges the font fallback mechanism exports them with different font and this causes wrong glyph rendering in the resulted PDF.

The following code snippet shows how the Wingdings characters can be modified so that they are correctly exported to PDF when converting from WordsProcessing's RadFlowDocument:
RadFlowDocument document = new DocxFormatProvider().Import(File.ReadAllBytes(@"test_document.docx"));
foreach (Run run in document.EnumerateChildrenOfType<Run>())
{
    if (run.FontFamily.GetActualValue(document.Theme).Source.Contains("Wingdings"))
    {
        StringBuilder modifiedText = new StringBuilder();

        foreach (char character in run.Text)
        {
            modifiedText.Append(character > 256 ? character : (char)(character + 61440));
        }

        run.Text = modifiedText.ToString();
    }
}
Workaround: When creating a RadFixedDocument:
using (RadFixedDocumentEditor editor = new RadFixedDocumentEditor(this.fixedDocument))
{
	byte[] data = File.ReadAllBytes(@"CustomFont.ttf");
	FontsRepository.RegisterFont(new FontFamily("CustomFont"), FontStyles.Normal, FontWeights.Normal, data);
	FontBase customFont;
	FontsRepository.TryCreateFont(new FontFamily("CustomFont"), FontStyles.Normal, FontWeights.Normal, out customFont);
	editor.CharacterProperties.Font = customFont;
	string text = "w";

	StringBuilder modifiedText = new StringBuilder();
	foreach (char character in text)
	{
		modifiedText.Append(character > 256 ? character : (char)(character + 61440));
	}

	text = modifiedText.ToString();

	editor.InsertRun(text);
}

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.

The hierarchical document structure is a means to describe the PDF document structure, which is currently not supported. See 10.6.1 Structure Hierarchy on 856 page of the PDF specification for details.
This document structure is an alternative to the standard PDF structure and most non-Adobe software does not support it.

The document might have been created with Adobe software like Adobe LiveCycle Designer. Very often the document contains some fallback text in the standard PDF structure like:
"Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document."
"The document you are trying to load requires Adobe Reader 8 or higher. You may not have the Adobe Reader installed or your viewing environment may not be properly configured to use Adobe Reader. For information on how to install Adobe Reader and configure your viewing environment please see  http://www.adobe.com/go/pdf_forms_configure."
"For the best experience, open this PDF portfolio in Acrobat X, Reader X, or later."

Although Lab color space is currently unsupported, the provider should not throw exceptions that break the whole file import.

When a TrueType font is defined, the mapping of character codes to glyph indices depends on the built-in cmap table mappings defined in the font and the Encoding property defined in the PDF dictionary.

However, the current implementation maps all characters with cmap tables for Microsoft Symbolic and Macintosh Roman, which causes incorrect mapping results, e.g. space characters are mapped to an Ê glyph.

The issue is also described in the following public item: TryGetCharCode for OpenTypeFont uses wrong cmap and returns wrong charcode.

Workaround: Change the font  of the TextBoxField's widget appearance:
foreach (var widget in field.Widgets)
{
    widget.TextProperties.Font = FontsRepository.Helvetica;
}