Completed
Last Updated: 17 Jul 2017 07:12 by ADMIN
This is because PdfProcessing does not export Annotation Flags and this way all annotations has Print flag set to false.

Available in Release Version R2 2017 SP1.
Unplanned
Last Updated: 10 Jul 2017 13:01 by ADMIN
According to PDF specification widget's parent field should always be terminal field and should have FieldType specified. However, there are documents which are generated without fulfulling this rule and we need to consider handling this scenario without any exceptions.
Unplanned
Last Updated: 26 Apr 2017 10:04 by ADMIN
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
Unplanned
Last Updated: 03 Apr 2017 08:46 by ADMIN
If the MatrixPosition has Matrix (1, 0, 0, 1, 20, 10) the Table should be positioned with top-left coordinate (20, 10). Instead, it is wrongly positioned at (40, 20).
Completed
Last Updated: 20 Mar 2017 09:10 by ADMIN
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
Completed
Last Updated: 16 Mar 2017 13:32 by ADMIN
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
Unplanned
Last Updated: 14 Mar 2017 08:16 by ADMIN
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.
Unplanned
Last Updated: 13 Feb 2017 15:50 by ADMIN
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();
    }
}
Unplanned
Last Updated: 13 Jan 2017 14:44 by ADMIN
ADMIN
Created by: Deyan
Comments: 0
Category: PdfProcessing
Type: Bug Report
1
Measuring big paragraphs is time consuming and may be optimized.
Unplanned
Last Updated: 13 Jan 2017 14:43 by ADMIN
Currently every text fragment is exported by specifying all its properties. When there are many fragments one after another we may skip specifying the properties for every single fragment. This will improve both memory and time consumption performance.
Unplanned
Last Updated: 12 Jan 2017 16:37 by ADMIN
Unplanned
Last Updated: 09 Dec 2016 14:55 by ADMIN
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.
Completed
Last Updated: 18 Nov 2016 08:41 by ADMIN
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.
Completed
Last Updated: 17 Oct 2016 17:25 by Carl
The issue is reproducible only with nested tables - tables positioned inside some other table cell. When using simple tables the text is always wrapped and rendered correctly. This may be used as a workaround for scenarios which allow replacing nested tables with simple ones.
Unplanned
Last Updated: 07 Oct 2016 05:29 by ADMIN
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.
Unplanned
Last Updated: 22 Sep 2016 17:02 by ADMIN
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.
Unplanned
Last Updated: 23 Aug 2016 10:51 by ADMIN
When some character is not supported by the font, the fallback mechanism should try finding some other font that is capable of rendering the unsupported character. However, RadPdfProcessing fallback mechanism does not always find the correct font which sometimes result in wrong glyph visualization or in missing glyph.

Workaround: Font that supports these special characters may be used. This way the fallback mechanism will not be needed to export the PDF text.
Completed
Last Updated: 02 Jul 2016 21:05 by ADMIN
When a source RadFixedDocument is merged to a target RadFixedDocument, the content of the source document is cleared.
Completed
Last Updated: 18 May 2016 10:36 by ADMIN
This may cause either big distance between some glyphs, or overlapping glyphs.
1 2 3 4 5