PdfFormatProvider: When Arial Narrow Bold fond is set in the document the font-weight is lost when converting to PDF.
Workaround:
var fontData = File.ReadAllBytes(@"C:\Downloads\arial-narrow\arialnb.ttf");
FontsRepository.RegisterFont(new System.Windows.Media.FontFamily("Arial Narrow"), FontStyles.Normal, FontWeights.Bold, fontData);
Currently, the text extraction is following the behavior (text distance) as exported with Adobe.
Provide a setting in TextFormatProvider in order to keep the original distance as in the PDF document.
When exporting PDF documents containing images different than Jpeg and Jpeg2000 the PdfProcessing is using by default the ImageSharp library in order to convert these images to Jpeg.
It seems there is an issue in the older version of the ImageSharp library: Saving a PNG as Jpeg only processes a part of the image on .NET 6.
Workaround: This issue seems to be fixed in the current version (2.0.0) of the ImageSharp library.
When a document containing a SignatureField is exported with the IsEncrypted property set to true, a not set UserPassword is required to open it, which makes it impossible to be opened.
Workaround: Exporting with AES256 encryption does not have this problem:
provider.ExportSettings = new PdfExportSettings
{
IsEncrypted = true,
EncryptionType = EncryptionType.AES256
};
URI Action with invalid mailto URL scheme - mailto:***@***.**(E-mail) can be imported but trying to merge or clone the document throws UriFormatException: 'Invalid URI: The hostname could not be parsed.'
Workaround: Remove the annotations that contain invalid Uri:
PdfFormatProvider provider = new PdfFormatProvider();
this.pdfDocument = provider.Import(memory);
foreach (var page in this.pdfDocument.Pages.ToList())
{
List<Link> links = page.Annotations.Where(a => a.Type == AnnotationType.Link).Select(a => a as Link).ToList();
foreach (var link in links)
{
Uri uri;
UriAction uriAction = link.Action as UriAction;
try
{
uri = uriAction.Uri;
}
catch (UriFormatException)
{
page.Annotations.Remove(link);
}
}
}
list-style is not imported correctly when importing from CSS classes defined in the same file
Case 1: importing from CSS classes defined in the same file
Case 2: inline style
<html>
<head>
</head>
<body>
<p>This is an unordered list with list-style:none</p>
<ul>
<li style="list-style:none;">Item 1</li>
<li style="list-style:none;">Item 2</li>
</ul>
<p>This is an unordered list with list-style:disc</p>
<ul>
<li style="list-style:disc;">Disc Item 1</li>
<li style="list-style:disc;">Disc Item 2</li>
<li>Some nested list </li>
</ul>
</body>
</html>
When exporting a specific document with a CIDFontType0 font (Korean TAWBUL+HGGGothicssiP80g or BPRSCV+HGGGothicssiP60g) the document is wrongly exported which leads to missing content.
Workaround:
After import you can change the font:
pdfDocument = provider.Import(memory);
FontBase malgunGothicFont;
FontsRepository.TryCreateFont(new FontFamily("Malgun Gothic"), out malgunGothicFont);
foreach (RadFixedPage page in pdfDocument.Pages)
{
foreach (ContentElementBase element in page.Content)
{
TextFragment textFragment = element as TextFragment;
if (textFragment != null && (textFragment.Font.Name == "TAWBUL+HGGGothicssiP80g" || textFragment.Font.Name == "BPRSCV+HGGGothicssiP60g"))
{
textFragment.Font = malgunGothicFont;
}
}
}
Currently, a known limitation is:
RadPdfProcessing currently supports only signing of a single signature field. Signing more than one signature field will result in invalidation of all signatures except the last one.
Please support signing multiple signature fields. We are heading into 2022 and it's more essential than ever to be able to sign multiple signature fields.
When importing a document containing text fragment with a wrong Type3 font set the glyph cannot be obtained from the font and an exception is thrown: System.InvalidOperationException: 'Cannot create glyph with charcode: <<>>'
When the Font`s Widths array contains entries defined as Indirect references an exception is thrown: System.ArgumentException: 'The IndirectReference type cannot be converted to a real numeric value.'
According to the Pdf Specification: The glyph widths are measured in units in which 1000 units corresponds to 1 unit in text space.