If the PdfViewer is initialized with a default document, the display performance of this document will be a lot worse, compared to PDF documents that are loaded programmatically after the component is already on the web page.
The PDF standard allows two ways to configure Acro fields and relate them to inputs (widget annotations):
Adobe Acrobat supports both options. Telerik PdfProcessing supports only the first option, which is more commonly used. The PDF Viewer supports only the second option. If the PDF Viewer loads a file with the first configuration, the component saves new field values in such a way that they can't be retrieved by PdfProcessing. Moreover, if the PDF file is opened locally, it looks like the new values are there, but when you click on a field, the original value shows. The new value behaves like a placeholder rather than a real value.
Set the PdfViewer document (data) value to null. As a result, an endless loader will appear.
===
ADMIN EDIT
===
A possible workaround for the time being is to re-initialize the component after clearing the file: https://blazorrepl.telerik.com/cHYwQola24zzBOAd02.
The problem with the extra characters at the beginning of the PDF document has resurfaced.
The bytes returned by GetFileAsync() don't start with %PDF-, but with JS.ReceiveByteArray. Some PDF readers and my antivirus flag the file as corrupt or suspicious. I worked around it by stripping everything before the first %PDF- occurrence in the bytes before writing to disk.
Open the PDF Viewer component online demo and click the download button:
Expected - the PDF must be downloaded.
Current - the file is not downloaded.
When downloading files via the TelerikPdfViewer bytes are added before and after the PDF Dokument.
Browsers are able to show the documents but you get and error message if you try to open the downloaded document in Acrobar Reader or in a DMS.
The document attached was download from the demo on your web site.
After clicking the Print button, the pages are ordered incorrectly. Can be seen in the preview window.
Steps to reproduce:
1. Open https://demos.telerik.com/blazor-ui/pdfviewer/overview
2. Click the Print button
Trying to upload a large file from a mobile device breaks the component.
Step to reproduce:
The issue can be reproduced only in version 8.0.0
Related to PDF Viewer does not display editable Acro fields, which was fixed in version 8.0, but the problem with readonly Acro fields persisted.
This is a regression in version 7.0.0. Version 6.2.0 displays all the acro field values as expected.
When a user invokes a Search tool, their intention is to directly write a text to search, therefore the edit for the search text should be focused immediately. In the current implementation, users have to manually focus the edit all the time, which is really inconvenient.