When documents are exported to PDF, the creation date and modification date are not expected, or, when the time zone is with negative offset, the documents are invalid (detected by validation tools).

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.

using (var stream = File.OpenWrite("sample.xlsx"))
using (var workbook = SpreadExporter.CreateWorkbookExporter(SpreadDocumentFormat.Xlsx, stream))
using (var worksheet = workbook.CreateWorksheetExporter("My sheet"))
using (var row = worksheet.CreateRowExporter())
using (var cell = row.CreateCellExporter())
{
      cell.SetValue(string.Format("Error Value: {0} ", Encoding.ASCII.GetString(new byte[] { 8 })));
}

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.

Currently, signature flags, represented by the 'SigFlags' optional entry, are not imported and exported, and there is no API for setting them.
As a result, documents signed with RadPdfProcessing (or with RadPdfViewer) appear in Adobe Reader without the blue document message bar at the top (the analogue of the RadPdfViewer's SignaturePanel).

If the API is supported, setting the flag to 1 or 3 would ensure that the message bar would be visualized in Adobe Reader.

Support conversion of XPS documents to PDF using RadPdfProcessing.

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;
        }
    }
}

Add support for setting and exporting document metadata, like Title, Author and similar.

Provide a way to export filters.

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 project attached to the following feedback item: https://feedback.telerik.com/Project/184/Feedback/Details/249535-pdfprocessing-provide-a-way-to-rename-formfields to rename the duplicate fields.

Provide a way to change the Name of a FormField from the RadDocument.AcroForm.FormFields collection.

As a workaround, you could create a new instance of a FormField with the desired name, add the new field in the document and remove the old one. You can use the following approach:
   1) Create a new instance of FormField (with the desired name, passed in the constructor), which will play the role of a copy of a specific FormField
   2) Copy all properties from the original field (they all vary, depending on the concrete type of the FormField, for example CheckBoxField, etc.)
   3) Create a new widget for the new field, and copy all properties from the original field's widget into the new one.
   4) Remove the original field from the RadDocument.AcroForm.FormFields collection and add the new field.
   5) Remove the original widget from the corresponding page's annotation and add the new one.

Attached is a project demonstrating this approach for a CheckBoxField.

In a DOCX document, the users can define an image which is bigger than the size of the page. When such an image is at the beginning of the document and is converted with PdfFormatProvider, an additional page is added in the result PDF.

foreach (var image in document.EnumerateChildrenOfType<ImageInline>())
{
    var section = image.Paragraph.Parent as Section;
    if (image.Image.Height > section.PageSize.Height - section.PageMargins.Top - section.PageMargins.Bottom)
    {
        var height = section.PageSize.Height - section.PageMargins.Top - section.PageMargins.Bottom - (image.Paragraph.Spacing.SpacingAfter * (image.Paragraph.Spacing.LineSpacing - 0.97));
        image.Image.Size = new System.Windows.Size(image.Image.Width, height);
    }
}