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):

1. The field can be independent of the input widget. There can even be multiple inputs that point to the same field.
2. The field and the widget can be represented by the same object in the PDF file.

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.

To Reproduce

1. Open a file with Acro fields in the PDF Viewer with enabled form filling
2. Edit the fields and save the file.
3. Open the file with a desktop client like Adobe Acrobat Reader.
4. Click on a textbox.
5. Result - the old value shows. Instead, the new value should persist.
   

Hallo,

i want to Render PDF Files with the PDF Viewer Component.

The Data of the PDF is already fetched from the API when the PDF-Viewer starts Rendering the Loading animation appears and freezes.

After a few Seconds the PDF will be Rendered.

The size of the PDF File is about 5MB.

=====

TELERIK EDIT: Here is a possible workaround - replace the built-in PDF Viewer LoaderContainer with another one with a different animation Type.

<div class="pdfviewer-wrapper">
    <TelerikPdfViewer Height="600px" />

    @* With a Loading... label *@
    <TelerikLoaderContainer Class="pdf-loader-container"
                            OverlayThemeColor="@ThemeConstants.Loader.ThemeColor.Light"
                            Size="@ThemeConstants.Loader.Size.Large"
                            Visible="true" />

    @* Without a Loading... label *@
    @*<TelerikLoaderContainer Class="pdf-loader-container"
                                OverlayThemeColor="@ThemeConstants.Loader.ThemeColor.Light"
                                Visible="true">
            <Template>
                <TelerikLoader Size="@ThemeConstants.Loader.Size.Large"
                               Type="@LoaderType.Pulsing" />
            </Template>
        </TelerikLoaderContainer>*@
</div>

<style>
    .pdfviewer-wrapper {
        position: relative;
    }

    .pdf-loader-container,
    .k-pdf-viewer .k-loader-container {
        visibility: hidden;
    }

    .k-pdf-viewer:has(.k-loader-container:not([style*="none"])) + .pdf-loader-container {
        visibility: visible;
    }
</style>

@code {
    private byte[]? PdfViewerData { get; set; }
}

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:

1. Open this REPL example on a mobile device
2. Click the "Load Data" button.

The issue can be reproduced only in version 8.0.0