Title

KeyNotFoundException in DefaultAppearanceProvider.TryGetCurrentAnnotationAppearances when loading PDF with FreeText/Widget annotation containing invalid "/AP << /N 0 0 R >>" reference (likely macOS Preview-authored)

Product / Version

• Product: Telerik UI for WPF — RadPdfViewer / PdfProcessing (Telerik.Windows.Documents.Fixed.dll)
• Version: 2022.1.217.40
• Platform: .NET Framework 4.x, WPF, Windows

Summary

Loading a PDF containing an annotation with a broken appearance reference (/AP << /N 0 0 R >> — an indirect reference to object 0, which is reserved/invalid per the PDF spec) throws an unhandled KeyNotFoundException deep inside the rendering pipeline when the affected page is scrolled into view. This crashes the hosting WPF application, since the exception originates inside WPF's layout/render callback (OnRender) rather than during the initial PdfFormatProvider.Import() call, so it cannot be caught by application-level try/catch around import.

I found this appears to match a previously reported and fixed issue: "PdfViewer: KeyNotFoundException is thrown when loading a document with Free Text Annotation," fixed in Release 2024.3.924. I'd like confirmation this is the same root cause and whether 2024.3.924+ resolves it, or if this is a distinct case given the specific /N 0 0 R malformation I've isolated.

Steps to Reproduce

1. Load the attached PDF (page containing the annotation object shown below) into RadPdfViewer via PdfFormatProvider.Import() with ImportSettings = PdfImportSettings.ReadOnDemand.
2. Assign the resulting RadFixedDocument to RadPdfViewer.Document.
3. Scroll to the page containing the affected annotation.
4. Exception is thrown during WPF's render pass, not during import.

Full Stack Trace

System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Telerik.Windows.Documents.Fixed.Model.Annotations.MultiStateAppearances.get_Item(String stateName)
   at Telerik.Windows.Documents.Fixed.Utilities.Rendering.Annotations.DefaultAppearanceProvider.TryGetCurrentAnnotationAppearances(Annotation annotation, SingleStateAppearances& singleStateAppearances)
   at Telerik.Windows.Documents.Fixed.Utilities.Rendering.Annotations.DefaultAppearanceProvider.TryProvideAppearanceOverride(Annotation annotation, AnnotationAppearanceMode annotationAppearanceMode, FormSource& formSource)
   at Telerik.Windows.Documents.Fixed.Utilities.Rendering.Annotations.BaseAppearanceProvider.TryProvideAppearance(Annotation annotation, AnnotationAppearanceMode annotationAppearanceMode, FormSource& appearance)
   at Telerik.Windows.Documents.Fixed.Utilities.Rendering.Annotations.BaseAppearanceProvider.TryProvideAppearance(Annotation annotation, AnnotationAppearanceMode annotationAppearanceMode, FormSource& appearance)
   at Telerik.Windows.Documents.Fixed.Utilities.Rendering.FixedPageContentRenderingHelper.RenderNormalAnnotationAppearance(IFixedContentRenderer renderer, Annotation annotation)
   at Telerik.Windows.Documents.Fixed.UI.AnnotationAppearancesCanvas.DrawAppearance(DrawingContext drawingContext)
   at Telerik.Windows.Documents.Fixed.UI.AnnotationAppearancesCanvas.OnRender(DrawingContext dc)
   at System.Windows.UIElement.Arrange(Rect finalRect)
   at System.Windows.Controls.Canvas.ArrangeOverride(Size arrangeSize)
   at System.Windows.FrameworkElement.ArrangeCore(Rect finalRect)
   at System.Windows.UIElement.Arrange(Rect finalRect)
   at System.Windows.ContextLayoutManager.UpdateLayout()
   at System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
   at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
   at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)

Root Cause (identified via hex inspection of the source PDF)

The offending annotation object in the PDF:

181 0 obj
<< /AP << /N 0 0 R >>
   /M (D:20231128120931Z00'00')
   /Rect [ 67.664 412.788 527.774 446.2222 ]
   /AAPL:SFF true
   /F 4
   /DA (//Menlo-Regular 14 Tf 0 g)
   /AAPL:AKExtras
   << /AAPL:AKPDFAnnotationDictionary
      << /AP << /N 0 0 R >>
         ...

• /AP << /N 0 0 R >> is an indirect reference to object number 0, which is reserved by the PDF spec (head of the free-object list) and never resolves to a real object.
• The /AAPL:SFF, /AAPL:AKExtras, /AAPL:AKPDFAnnotationDictionary keys indicate this annotation was written by macOS Preview.app (Apple's proprietary annotation/markup extensions), consistent with a document that was signed or markup-annotated on a Mac before being distributed.
• DefaultAppearanceProvider.TryGetCurrentAnnotationAppearances does:

  singleStateAppearances = appearances[appearances.CurrentState];

with no existence/null check before indexing — when CurrentState doesn't resolve to a valid key (because the backing /N reference was never a valid object), this throws KeyNotFoundException uncaught.

Impact

This exception occurs during WPF's internal render callback, outside the call stack of the code that calls PdfFormatProvider.Import(), so it cannot be caught by a standard try/catch around import/load. It surfaces as a DispatcherUnhandledException on the UI thread and, without an application-level workaround, crashes the hosting application entirely.

What I'm asking Telerik to confirm

1. Is this the same root cause as the "KeyNotFoundException when loading document with Free Text Annotation" issue fixed in 2024.3.924, or a distinct case specific to the /N 0 0 R invalid-reference pattern?
2. Can you confirm 2024.3.924+ (or ideally your current latest) resolves this specific /N 0 0 R malformation, not just the FreeText-annotation case?
3. Is there a supported, non-reflection-based public API to validate/sanitize an annotation's appearance state before rendering, so we can defensively filter malformed annotations without waiting for a full version upgrade? (We are currently working around this via reflection into internal Appearances/MultiStateAppearances members, which is fragile across versions.)
4. Since TryGetCurrentAnnotationAppearances already has "Try" in its name implying safe failure, could this be hardened with a TryGetValue instead of the indexer, to fail gracefully rather than throw, for any similarly malformed future document?