Fix font width array parsing when entries are indirect object references

[VarunSaiTeja]

Problem

When parsing font dictionaries, FontDictionaryAccessHelper.GetWidths() iterates the /Widths array and expects every element to be a direct NumericToken. However, the PDF specification allows array elements to be indirect object references that resolve to numeric values.

When a width entry is an IndirectReferenceToken (e.g., 212 0 R resolving to value 763), the method throws InvalidFontFormatException: Token which was not a number found in the widths array.

This is particularly common in PDFs that use object streams (/Type /ObjStm) for storing font dictionaries, where individual width values may be stored as separate indirect objects.

Since PdfDocument.GetPage() wraps exceptions with PdfDocumentEncryptedException when the document is encrypted, the user-visible error is the misleading message: "Document was encrypted which may have caused error when retrieving page" — even though the actual issue is unrelated to encryption.

Fix

In GetWidths(), when an array element is not a NumericToken, attempt to resolve it via DirectObjectFinder.TryGet<NumericToken>() before throwing. The pdfScanner parameter is already available in the method signature.

Impact

Fixes page access failures on PDFs where font width arrays contain indirect references. Tested on a 400-page encrypted PDF that previously failed on 228 pages — all 400 pages now succeed.