RadPdfProcessing currently supports interactive forms whose data is defined directly in the document. To preserve them when importing and exporting documents, add support for import-export interactive forms based on the Adobe XML Forms Architecture (XFA).
From PDF 2.0 the XFA forms are depreciated.
Add support for Arrange Options (level placement):
When a PDF document is being imported, some of the characters may experience unexpected results while reading the font.
NOTE: the document is displayed in the MAUI/WPF/WinForms PdfViewer controls with missing parts of the text.
The PDF/A-1 standard uses the PDF Reference 1.4 and specifies two levels of compliance:
- PDF/A-1b - Its goal is to ensure reliable reproduction of the visual appearance of the document.
- PDF/A-1a - Its objective is to ensure that documents content can be searched and re-purposed. This compliance level has some additional requirements:
Since the PdfProcessing and its PdfFormatProvider is compliant with the PDF Reference 1.7. , the produced documents are created with this version as well:
From R1 2017 all annotations (including sound and video) are supported for import-export scenarios by using PdfStreamWriter class. These feedback item will be opened as we may add API for generating and inserting new sound annotations from scratch in the file.
When a source RadFixedDocument is merged to a target RadFixedDocument, the content of the source document is cleared.
WinAnsiEncoding it is imported as StandardEncoding since WinAnsiEncoding is still not implemented in RadPdfProcessing.
This is content stream operator that is used to close, fill and then stroke a PDF path geometry. Available in R3 2018 SP1 release.
When images are added to the document with non-default quality (PdfExportSettings.ImageQuality different that ImageQuality.High) , they are re-encoded, which uses a lot of memory and may cause OutOfMemoryException for large images. Workaround (works when inserting big JPEG images): In this case ImageQuality.High may be used and RadPdfProcessing will decode only the image headers to insert the image into the PDF file. As image pixels are not decoded with ImageQuality.High, there will be no OutOfMemoryException.
This would allow creating documents with preferences such us HideToolbar, HideMenubar, FitWindow, PrintScaling and all other viewer preferences specified in PDF format specification.
OutOfMemoryException is thrown when generating PDF with many pages each of which contains images, as all of the document model data is in-memory. The issue is fixed with the new PdfStreamWriter API. As an example, you may see the attached demo to the following feedback item: https://feedback.telerik.com/Project/184/Feedback/Details/213503-pdfprocessing-optimize-pdfstreamwriter-cache-in-order-to-reduce-memory-when-writ Available in LIB version: 2017.1.320
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.
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.
Currently, only images without transparency may be created with this class. Available in LIB version 2017.1.410.
This is causing issues when exporting the document to PDF from WordsProcessing - the pdf library tries to create the font, but cannot find it due to a different casing. When importing HTML document, the font-family property is read with small letters. Later, when converting the string containing the value, it is changed to title case. This issue will be reproducible with each font containing a name with a letter with casing different than the one of the other letters (exc. first capital letter), for example: Microsoft JhengHei