Error message:

System.InvalidCastException: 'Unable to cast object of type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Types.PdfArray' to type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Functions.FunctionObject'.'

Error message: 

System.InvalidCastException: 'Unable to cast object of type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Forms.FormFieldsTree' to type 'Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Types.PdfArray'.'

The standard fonts listed at http://docs.telerik.com/devtools/wpf/controls/radpdfprocessing/concepts/fonts#standard-fonts cannot be embedded in a document. Using one of them prevents the document from complying with PDF/A standard.

Add support for ToUnicode CMap stream.

A side effect of not supporting it is the following: exporting PDF document which, for example, contains German umlauts, to plain text, leads to wrong characters in the resulting text.

As possible workaround, the PdfFormatProvider instance of RadPdfViewer can be used to import the document. For example:

FormatProviderSettings settings = new FormatProviderSettings(ReadingMode.OnDemand);
PdfFormatProvider pdfViewerFormatProvider = new PdfFormatProvider(stream, settings);
 
RadFixedDocument document = pdfViewerFormatProvider.Import();
 
TextFormatProvider textFormatProvider = new TextFormatProvider();
String text = textFormatProvider.Export(document);

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.

Sometimes customers need to create documents using the CMYK colors to meet specific requirements for printing. Expose such functionality in PdfProcessing.

PDF/UA (PDF/Universal Accessibility) is the informal name for ISO 14289, the International Standard for accessible PDF technology.

The current implementation relies on valid cross-reference offsets in the PDF documents so that PDF objects are easily found and parsed. However, we may implement a mechanism for importing documents with invalid offsets for the objects inside the table.

More information is available in the Pdf Reference 1.7. Page 442 lists all predefined CMaps that should be imported and exported as PdfName objects. At this point, trying to import a document with such encoding, a NotSupportedException is thrown with message Encoding type is not supported.

When importing a document containing a specific image stream an exception is thrown.

Implement support for adding barcodes to a PDF document.

Wrong text appearance when editing field because of the wrong FieldFlag ("Ff") exported.

As one can use annotations we should support attachments per page or per pdf-file.

Some fonts don't include bold and italic font styles. These fonts can be exported with the default typeface, and additional transformation could be applied to the letters itself - e.g. skew transform for the italic.

Note: Make sure that this will also work when exporting to PDF in WordsProcessing.

Currently this operator is interpreted correctly only for Pattern colorspace. It also partially supports the rest of the colorspaces from R1 2018.

Available in R2 2018 Official Release Version.

This new API will not read/delete the existing PDF pages content and this would allow performance and memory efficient realization of the following scenarios: 

 - Merge PDF document pages from different PDF files.

 - Split PDF document pages to separate PDF files.

 - Append/Prepend PDF content to existing PDF pages.

Moreover, as this approach will not require reading/deleting existing PDF page content, it will not depend on complex PDF features and will depend only on the PDF file structure. This will allow processing of PDF documents which use less common PDF features which are currently not supported by the existing PdfProcessing API.


Available in R1 2017 Release

When creating a GradientStop, an alpha channel of the color could be applied. However, this setting is not respected it the result document and the gradient is with full opacity.

Steps to reproduce:
1. Create a gradient with an alpha channel:

RadFixedDocument document = new RadFixedDocument();
RadFixedPage page = document.Pages.AddPage();
FixedContentEditor containerEditor = new FixedContentEditor(page);

LinearGradient linearGradient = new LinearGradient(new Point(0, 0), new Point(30, 30));
linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 207, 0), 0));
linearGradient.GradientStops.Add(new GradientStop(new RgbColor(10, 0, 102, 204), 1));

containerEditor.GraphicProperties.FillColor = linearGradient;
containerEditor.DrawRectangle(new Rect(10, 10, 48, 29));

2. Export the document to PDF

Observed: The alpha channel is not respected and the gradient is with full opacity

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

A free text annotation displays text directly on the page. Unlike an ordinary text annotation, a free text annotation has no open or closed state; instead of being displayed in a pop-up window, the text is always visible.

The executing of the PostScriptReader`s Read method takes a lot of time when iterating content streams with many Path geometries.