The current implementation of IDisposable implements a simple Dispose method which releases the inner stream resource. However, if the PdfStreamWriter instance is not disposed explicitly by calling Dispose() or by surrounding it in "using" clause, then the inner Stream resource is not Disposed as well. The same applies for PdfFileSource class.

We should implement the IDisposable pattern in a way that the GC disposes the inner stream if needed when collecting the PdfStreamWriter/PdfFileSource class instances.

This leads to keeping a lot of memory when exporting pages from multiple PdfFileSource instances which are created from MemoryStream.

Available in LIB version: 2017.1.320

Currently, when writing RadFixedPage the page instance reference is cached, as well as its content resources (images and fonts). This cache is important as it allows to reuse pages, images and fonts without writing them multiple times in the result PDF document. However, it needs to be optimized in order to consume less memory. 

The attached demo shows how to create 2500 pages with big images (different image on each page). With the current version, this demo consumes about 3 GB memory which may lead to OutOfMemoryException. With the optimization that will be introduced in LIB version, the same demo will consume about 20 MB memory for writing this big PDF document.

Available in LIB version: 2017.1.320

Currently, PdfStreamWriter writes only PDF pages.

If we implement API for merging multiple pages or whole documents we would be able to preserve links between pages (which are currently being corrupted).

Merging whole documents would also allow preserving document properties (bookmarks, interactive forms, ...). For a more detailed list of the unsupported document properties you can refer to our documentation: https://docs.telerik.com/devtools/document-processing/libraries/radpdfprocessing/formats-and-conversion/pdf/pdfstreamwriter/features.

We may also implement API for adding initial document properties from some existing PDF file.

This would ensure preserving the existing PDF file pages and document properties untouched and additionally would allow making a few modifications to the file. By appending bytes to existing PDF file one may achieve:

 - Modifying specific pages content and properties.
 - Adding new pages to pages collection.
 - Modify some document properties (such as Bookmarks).
 - Edit interactive forms field values.
 - Add digital signatures to existing documents.

When opened in Adobe Reader it says that the file "claims compliance". However, when verifying the compliance with some validation tools there seem to be some issues mainly related but not limited to fonts. 

Matte color is used for preblending images with some background color, using the SMask. Matte color is specified using the optional 'Matte' entry for the SMask object.

See PDF 1.7 specification, page 554-555:

Matte
array
(Optional; PDF 1.4) An array of component values specifying the matte color with which the image data in the parent image has been preblended. The array consists of nnumbers, where n is the number of components in the color space specified by the ColorSpace entry in the parent image’s image dictionary; the numbers must be valid color components in that color space. If this entry is absent, the image data is not preblended.

The public API may be implemented as property of PdfExportSettings.

Implementing this feature would help to easily workaround issue with PdfProcessing documents that cannot be opened on devices with iOS version 10.2 (due to the default FlateDecode compression).

For example, when some PDF file has uncompressed contents we may import it and apply better compression to the stream objects. Ensure that all the content inside the document is compressed.

Currently, we have the following options for PDF export optimizations:

• ImageQuality
  

  pdfFormatProvider.ExportSettings.ImageQuality = ImageQuality.Low;

• ImageCompression
  

  pdfFormatProvider.ExportSettings.ImageCompression = new ImageFilterTypes[] { ImageFilterTypes.FlateDecode };

• StreamCompression
  

  pdfFormatProvider.ExportSettings.StreamCompression = new StreamFilterTypes[] { StreamFilterTypes.FlateDecode };

• FontEmbeddingType (Q2 2024)
  

  pdfFormatProvider.ExportSettings.FontEmbeddingType = FontEmbeddingType.Subset;

  We introduced an option of exporting subsets of True Type Fonts (*.ttf) for the .NET Standard version of the library.

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.

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.

These images are defined directly in the PDF page content stream with BI and EI operators. Currently InvalidCastException is thrown when document with such images is imported.

Available in R1 2018 SP2 release version.

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 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 would allow to encrypt documents only with Owner Password and not showing password dialog when disabling some PDF features permissions. The customer should be able to disable printing, text and graphic selection and extraction, page rotations and others. The full specification of all permission bits may be seen in Table 3.20 on page 124 in PdfReference 1.7. On page 120 in PdfReference 1.7 are described the User and Owner passwords.

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.

PDF Editor: the pdfiewer will now have a feature to perform the following:

Sort pages by dragging and dropping selected pages.
After adding stamps/annotations on the page, user will be able to move around those objects by dragging and dropping.

Possibility to convert a PDF file to EPS file.

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