When merging, only the widgets are copied but not their fields. This can lead to ArgumentNullException when exporting the document. Implement copying the fields and consider cases which include collision of names of the fields.

Workaround:
Repair the generated document using the following code:
foreach (Widget widget in this.pdfDocument.Annotations.Where(annot => annot.Type == AnnotationType.Widget))
{
    if (!this.pdfDocument.AcroForm.FormFields.Contains(widget.Field.Name))
    {
        this.pdfDocument.AcroForm.FormFields.Add(widget.Field);
    }
}
In case of Name collision, you can use the attached project or the attached project to the following feedback item to rename the duplicate fields: Provide a way to rename FormFields.

This is reproducible with specific PDF files which use custom Encoding for the fonts of the field widgets. 

WORKAROUND: Change the font of VariableContentWidgets before editing the field value. You should additionally call RecalculateContent() method of these widgets if the value of their corresponding fields is not edited. The following method may be used for changing the font of all existing widgets in the document:

private static void FixEncodingIssues(RadFixedDocument document)
{
    foreach(Annotation annotation in document.Annotations)
    {
        VariableContentWidget widget = annotation as VariableContentWidget;

        if(widget != null)
        {
            widget.TextProperties.Font = FontsRepository.Helvetica;
        }
    }
}

Table and table cell borders are not evaluated according to inheritance and conflict resolution rules. A conflict will occur when different borders from the table and table cell are overlapping. 

The GetActualValue method of the TableBorders and TableCellBorders could potentially return an incorrect value in some of the following scenarios:

Scenario 1:
A table has cell spacing set to 0. Meaning that the table and table cell borders will overlap.
The table borders have defined all of its borders with border style "Single".
The table cell borders have all of its borders defined with border style "None".

Expected result: the resulting borders should have the border style set to "None" for the location where the table and the cell borders are overlapping.

Scenario 2:
A table has explicitly defined that its right border is with border style "None".
The table has a table style applied with defined border style of type "Single" for all table borders.

Expected result: All of the table borders except the right border should have border style of "Single".

The problem is mostly visible when exporting to PDF and RTF format.

When importing color space defined as an external resource name, a NotSupportedColorSpaceException: 'CS0 color space is not supported.' is thrown.

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

For example, importing URI Action with invalid mailto URL scheme - mailto:***@***.**(E-mail), throws UriFormatException: 'Invalid URI: The hostname could not be parsed.'

The issue is observed with tables that have a specific width (in inches or percents) but whose columns do not have width specified. MS Word renders such tables expanded to their full width. For tables with 100% width, they have to expand to the entire width of the page. The same behavior is expected in the PDF export.

As a common side effect, when specific text alignment (e.g. center or right) is applied to a paragraph within a table cell, and the table is with specified width, but the column is auto-sized (without set width), then the text alignment seems as not respected. Actually the problem is that the column table is shrunk to the text width.

Workaround: this may be used before exporting the RadFlowDocument instance to PDF:

foreach (Table table in document.EnumerateChildrenOfType<Table>())
{
    table.LayoutType = TableLayoutType.FixedWidth;
}


Workaround 2:

Set specific width to the auto-sized columns (to any of the cells in the columns):

cell.PreferredWidth = new Telerik.Windows.Documents.Flow.Model.Styles.TableWidthUnit(500);

Available in R1 2018 SP2 release version.

Formulas like =0.0001/10 or formulas that produce small values results in 0 instead of exponential numbers.


Available in LIB version: 2017.1.313

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 current implementation uses System.Windows.Media.Imaging.BitmapImage class in order to take the image pixels for the PDF export. However, BitmapImage class throws NotSupportedException when being initialized with a WMF or EMF image.

WORKAROUND: WMF and EMF images may be converted to PNG images before the PDF export. The following code snippet shows how to convert all inline WMF image to PNG images by using System.Drawing.Image class:

private static void ConvertInlineWmfImagesToPng(RadFlowDocument document)
{
    foreach (ImageInline image in document.EnumerateChildrenOfType<ImageInline>())
    {
        if (image.Image.ImageSource.Extension.Equals("wmf", StringComparison.InvariantCultureIgnoreCase))
        {
            using (MemoryStream wmfImageStream = new MemoryStream(image.Image.ImageSource.Data))
            {
                using (MemoryStream pngImageStream = new MemoryStream())
                {
                    var imageDrawing = System.Drawing.Image.FromStream(wmfImageStream);
                    imageDrawing.Save(pngImageStream, ImageFormat.Png);
                    byte[] pngBytes = pngImageStream.ToArray();
 
                    image.Image.ImageSource = new ImageSource(pngBytes, "png");
                }
            }
        }
    }
}

ArgumentException with clarification similar to  "'\u001f', hexadecimal value 0x1F, is an invalid character." is thrown when trying to export document containing characters which are not supported in XML document - such as some control characters like 0x00, 0x1F, 0x1B, etc. Such characters are described in the XML specification here: https://www.w3.org/TR/xml/#charsets.

Although the escaped strings are not supported (see  https://feedback.telerik.com/Project/184/Feedback/Details/190228 ), the library could prevent the exception and export the document successfully by skipping such characters.

Workaround: remove such characters before the export. Check the following StackOverflow answer for some ideas on code for replacing the characters: http://stackoverflow.com/a/14323524/259206

Fix available in R3 2018 SP1 release.

Exporting document with a missing image is caused by handled Exception on import for DecodeParms containing null or stream object. Currently, PdfProcessing supports only decode parameters containing simple types. The case when some dictionary value is null or stream object should be implemented.

Another case is when the whole dictionary/stream is null. In this case, an ArgumentNullException is thrown.

The EI keyword defines an operator for ending the image data. When the stream contains the same sequence, the parser treats that as an end of the image data. As a result, the image and the following content cannot be properly parsed and there is missing content when the document is visualized.

ArgumentException is thrown when importing an RTF document which has a font size is set to zero (\fs0).

KeyNotFoundException is thrown when importing RTF document which has an invalid Font Family name.

By specification, the InteractiveForm fields can have the same name if they are descendants of a common ancestor. Such fields are different representations of the same underlying field; they should differ only in properties that specify their visual appearance. When such a document is imported an ArgumentException: 'An item with the same key has already been added.' is thrown.

The checkbox state is not correctly imported when the value is not specified

Workaround:

private static void WorkaroundFieldsIssue(RadFlowDocument flowdocument)
{
    foreach (FieldCharacter fieldCharacter in flowdocument.EnumerateChildrenOfType<FieldCharacter>().ToList())
    {
        // only for start
        if (fieldCharacter.FieldCharacterType == FieldCharacterType.Start)
        {
            if (fieldCharacter.FieldInfo.Separator != null && fieldCharacter.FieldInfo.Separator.Parent == null)
            {
                Paragraph parent = fieldCharacter.FieldInfo.End.Paragraph;
                int index = parent.Inlines.IndexOf(fieldCharacter.FieldInfo.End);

                fieldCharacter.FieldInfo.End.Paragraph.Inlines.Insert(index, fieldCharacter.FieldInfo.Separator);
            }
        }
    }
}

The exception is thrown with the message "Password is not correct" even when the user password is correct. This issue occurs for specific encryption algorithm parameters only.