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.
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. Workaround: Repair the generated document using the following code: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.foreach
(Widget widget
in
this
.pdfDocument.Annotations.Where(annot => annot.Type == AnnotationType.Widget))
{
if
(!
this
.pdfDocument.AcroForm.FormFields.Contains(widget.Field.Name))
{
this
.pdfDocument.AcroForm.FormFields.Add(widget.Field);
}
}
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.
Table and table cell borders are not evaluated according to inheritance and conflict resolution rules. A conflict will occur when different borders from the table and table cell are overlapping. The GetActualValue method of the TableBorders and TableCellBorders could potentially return an incorrect value in some of the following scenarios: Scenario 1: A table has cell spacing set to 0. Meaning that the table and table cell borders will overlap. The table borders have defined all of its borders with border style "Single". The table cell borders have all of its borders defined with border style "None". Expected result: the resulting borders should have the border style set to "None" for the location where the table and the cell borders are overlapping. Scenario 2: A table has explicitly defined that its right border is with border style "None". The table has a table style applied with defined border style of type "Single" for all table borders. Expected result: All of the table borders except the right border should have border style of "Single". The problem is mostly visible when exporting to PDF and RTF format.
TableRow which has defined an only val attribute of the trHeight is imported as a row with auto height. By the specification, this is right, but MS Word takes the val value as row height. Also MS Word exports "At Least" row height with only 'val' set.
Workaround: Iterate through the table rows and set them HeightType to Exact or AtLeast:
foreach (var row in this.document.EnumerateChildrenOfType<TableRow>())
{
row.Height = new TableRowHeight(HeightType.AtLeast, row.Height.Value);
}
This is reproducible with specific PDF files which use custom Encoding for the fonts of the field widgets. WORKAROUND: Change the font of VariableContentWidgets before editing the field value. You should additionally call RecalculateContent() method of these widgets if the value of their corresponding fields is not edited. The following method may be used for changing the font of all existing widgets in the document: private static void FixEncodingIssues(RadFixedDocument document) { foreach(Annotation annotation in document.Annotations) { VariableContentWidget widget = annotation as VariableContentWidget; if(widget != null) { widget.TextProperties.Font = FontsRepository.Helvetica; } } }
Incorrect timestamp of a DateTime with custom number format.
Expected:
Actual:
In the document produced by the mail merge, the date time and numeric formatting applied are not respected and the value is in its default format.
CryptographicException is thrown when saving with PdfStreamWriter or importing with PdfFormatProvider.
The exception: System.Security.Cryptography.CryptographicException: 'The input data is not a complete block.'
When loading some PDF documents with German culture, part of the text got missing.
Workaround: set English culture before loading the document
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");
When the last element in a table cell is an empty paragraph, the latter is skipped and not imported. It should be imported even if it's the only paragraph in the cell, as its properties could affect the layout and presentation (borders, colors, spacings).
When xlsx/docx document is imported, and its main story is with non-default name ('workbook. xml'/'document.xml'), e.g. workbook2.xml/document2.xml, NullReferenceException is thrown and the document is not imported. Note: Such documents are usually produced after conversion from a template dotx/xlsm.