This is not quite a valid PDF file scenario according to PDF file specification. However, we may try handling it in order to show the correct number of pages. When the kid is of type Pages, it should be added to the pages traversal recursion only the first time it is met.
When importing a document containing a single associated widget annotation merged into the field dictionary the field is skipped on import and an exception is thrown.
According to the PDF Specification: Field Dictionaries: Kids:
An array of indirect references to the immediate children of this field.
In a non-terminal field, the Kids array is required to refer to field dictionaries that are immediate descendants of this field. In a terminal field, the Kids array ordinarily must refer to one or more separate widget annotations that are associated with this field. However, if there is only one associated widget annotation, and its contents have been merged into the field dictionary, Kids must be omitted.
A memory leak in RadPdfViewer when the control gets removed from the visual tree.
To work this around, use the reflection API to access the leaking VisualTarget objects and call their Dispose method manually.
var pdfViewer = hostBorder.Child as RadPdfViewer;
if (pdfViewer != null)
{
var canvas = viewer.ChildrenOfType<Canvas>().FirstOrDefault(x => x.GetType().Name.Contains("ContentElementsCanvas"));
var visualTargetsDictionaryField = canvas.GetType().GetField("pageNumberToVisualTarget", BindingFlags.NonPublic | BindingFlags.Instance);
var visualTargetsDictionary = (Dictionary<int, List<VisualTarget>>)visualTargetsDictionaryField.GetValue(canvas);
foreach (KeyValuePair<int, List<VisualTarget>> target in visualTargetsDictionary)
{
for (int i = 0; i < target.Value.Count; i++)
{
VisualTarget item = target.Value[i];
item.RootVisual = null;
item.Dispose();
}
}
}
hostBorder.Child = null;
hostBorder.Child = new RadPdfViewer() { Document = newDocument };
Currently, the PdfProcessing document model is providing support only for a single function in the Function entry.
According to the PDF Specification: Function: A 1-in, n-out function or an array of n 1-in, 1-out functions.
This action is usually linked to a Button field and with it, the user of the application may revert all field values to their defaults.
Some colors are changed due to incorrect import of some graphic state colors.
Some lines on attached files are to thick. Other pdf programs shows that correctly.
Regards
Janez
The performance of loading the thumbnails is decreased with the removing of the cache in PdfViewer. Possible reason is that the pages are no longer loaded asynchronously. Steps to reproduce: - Open the SDK with the thumbnails for PDFViewer. - Notice that the load of the thumbnails is slow.
Changing the value of the DocumentSource property at runtime causes the RadPdfViewer to display a busy indicator and not update the displayed PDF file with the new one.
To work this around, derive from the RadPdfViewer and create a new dependency property for the property of the type of PdfDocumentSource (for example, from your view model). In its callback method, call the SetDocumentSource method of the derived RadPdfViewer by passing the new value:
public class MyPdfViewer : RadPdfViewer
{
public PdfDocumentSource PdfDocumentSource
{
get { return (PdfDocumentSource)GetValue(PdfDocumentSourceProperty); }
set { SetValue(PdfDocumentSourceProperty, value); }
}
public static readonly DependencyProperty PdfDocumentSourceProperty =
DependencyProperty.Register("PdfDocumentSource", typeof(PdfDocumentSource), typeof(MyPdfViewer), new PropertyMetadata(new PropertyChangedCallback(OnDocumentSourceChanged)));
private static void OnDocumentSourceChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
MyPdfViewer viewer = (MyPdfViewer)d;
viewer.SetDocumentSource((PdfDocumentSource)e.NewValue);
}
}<local:MyPdfViewer x:Name="pdfViewer" PdfDocumentSource="{Binding MyViewModelPropertyOfTypePdfDocumentSource}" />