Approved
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).
Approved
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.
Approved
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();
    }
}
Approved
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.
Approved
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.
Approved
Last Updated: 12 Jan 2017 16:37 by ADMIN
Approved
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.
Approved
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.
Approved
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.
Approved
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.
1 2 3