Last Updated: 28 Feb 2019 13:55 by ADMIN
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. 
Last Updated: 31 Jan 2019 13:30 by ADMIN
Created by: Tanya
Comments: 4
Category: PdfProcessing
Type: Bug Report
When merging, only the widgets are copied but not their fields. This can lead to ArgumentNullException when exporting the document. Implement copying the fields and consider cases which include collision of names of the fields.

Repair the generated document using the following code:
foreach (Widget widget in this.pdfDocument.Annotations.Where(annot => annot.Type == AnnotationType.Widget))
    if (!this.pdfDocument.AcroForm.FormFields.Contains(widget.Field.Name))
In case of Name collision, you can use the attached project or the attached project to the following feedback item to rename the duplicate fields: Provide a way to rename FormFields.
Last Updated: 07 Mar 2019 08:39 by ADMIN
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
Last Updated: 22 Nov 2019 08:08 by ADMIN
By specification, the InteractiveForm fields can have the same name if they are descendants of a common ancestor. Such fields are different representations of the same underlying field; they should differ only in properties that specify their visual appearance. When such a document is imported an ArgumentException: 'An item with the same key has already been added.' is thrown.
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.
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.
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();
Last Updated: 17 Sep 2019 13:46 by ADMIN

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.
Last Updated: 07 Nov 2017 07:39 by ADMIN
InvalidOperationException is thrown when exporting font that is available but not used.

The stack trace is as follows:
   at System.Linq.Enumerable.Max(IEnumerable`1 source)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.Cid.CidSet.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.CalculateCidSet(IPdfExportContext context, CidFontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.<>c__DisplayClass34.<CopyPropertiesFrom>b__30()
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Utilities.PdfObjectsExtensions.ToPrimitive[P,T](PdfProperty`1 pdfProperty, Func`2 convertToPrimitive, Func`1 getDefaultValue)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontDescriptor.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontObject.CopyPropertiesFromOverride(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.CidFontObject.CopyPropertiesFrom(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Model.Elements.Fonts.Type0FontObject.CopyPropertiesFromOverride(IPdfExportContext context, FontBase font)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Export.PdfExporter.WriteFontsFromContext(PdfWriter writer, IPdfExportContext context)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.Export.PdfExporter.Export(IRadFixedDocumentExportContext context, Stream output)
   at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfFormatProvider.ExportOverride(RadFixedDocument document, Stream output)
   at Telerik.Windows.Documents.Common.FormatProviders.FormatProviderBase`1.Export(T document, Stream output)
Last Updated: 04 Sep 2018 12:35 by ADMIN
The issue may be reproduced by opening the attached PDF in Adobe Reader. Although the viewer initially shows the characters correctly, when you start typing in the TextBox, the umlaut/diacritics characters get corrupted. In other PDF viewers, the umlaut characters are handled correctly, so the issue seems to related to concrete Adobe Reader encoding handling implementation. The diacritic characters are handled incorrectly in other viewers as well (e.g. Chrome).
Last Updated: 31 Jan 2019 16:26 by ADMIN
When a document is exported with a cross-reference stream, the stream is missing the required according to the specification Length property. Although most of the viewers open the document without any issues, some cannot. Such documents cannot be opened in MS Edge.
Last Updated: 09 Oct 2019 13:11 by ADMIN
Trying to clone the Signature of a SignatureField leads to InvalidOperationException as the FieldName of the cloned signature is already set.
Last Updated: 25 Apr 2018 08:54 by ADMIN
This exception seems to be related to AES algorithm PaddingMode property. 
Last Updated: 12 Oct 2017 08:26 by ADMIN
If a PDF with a TextBoxField is created with a corresponding Widget, the text is actually long enough to be broken in more than one line and AllowScroll is set to true, upon opening the file in Adobe, the text is not visible. The field actually does have an appearance which can be seen upon inspection of the document but for some reason it is not visualized.

Another issue seems to be a different manifestation of the same problem: When the text is long and AllowScroll is false, the text will be visible, but will be misplaced. The issue is caused by the length of the text because the same field with a shorter text that can fit in the widget's rectangle will be displayed correctly. 
Last Updated: 03 Jun 2019 10:52 by ADMIN
Some documents result in glyphs with wrong widths after import-export. Widths are mixed making some of them to overlap and others to have bigger distance.
Last Updated: 09 Sep 2019 17:18 by ADMIN

When a TrueType font is defined, the mapping of character codes to glyph indices depends on the built-in cmap table mappings defined in the font and the Encoding property defined in the PDF dictionary.

However, the current implementation maps all characters with cmap tables for Microsoft Symbolic and Macintosh Roman, which causes incorrect mapping results, e.g. space characters are mapped to an Ê glyph.

The issue is also described in the following public item: TryGetCharCode for OpenTypeFont uses wrong cmap and returns wrong charcode.

Workaround: Change the font  of the TextBoxField's widget appearance:
foreach (var widget in field.Widgets)
    widget.TextProperties.Font = FontsRepository.Helvetica;

Last Updated: 01 Oct 2019 11:43 by ADMIN
If ImageInline's size is set through its Size property and not through Height or Width, the given size is not respected on export.
Last Updated: 10 Oct 2019 14:09 by ADMIN
By specification the destination string can be a string of up to 512 bytes. However, the current implementation supports strings of up to four bytes which leads to: ArgumentOutOfRangeException: 'bytes should be less or equal than 4.Parameter name: bytes'.
Last Updated: 01 Aug 2019 07:57 by ADMIN
Importing document containing TextBox widgets with NormalContentSource defining text properties, such as FontSize and Position, are exported with incorrect appearance when the value of the field is modified.
Last Updated: 16 Jan 2020 12:14 by ADMIN
Add support for documents with an invalid stream cross-reference table
1 2 3