The PDF Viewer may render parts of the contents as blank (empty space) and only form elements like checkboxes remain visible.

Test PDF file in ticket 1716925

• The PDF Viewer does not display the initial file if Zoom is set to FitToWidth or FitToPage. This is due to --scale-factor: NaN; --total-scale-factor: NaN; set on the PDF Viewer element.
• If the PDF Viewer initially shows with no loaded file, setting Zoom to FitToWidth or FitToPage initially or after opening a file leads to infinity zoom due to --scale-factor: Infinity; --total-scale-factor: Infinity; set on the PDF Viewer element.

The only scenario that works is to set the initial Zoom to a numeric value and have an open file by default.

The PDF Viewer may open certain files as empty, even though they have text and image content.

The issue occurs in version 14.0.0.

(Test file available in private ticket 1718294)

Hello,

we are using the PDFViewer Component. 

The zoom function usually works perfectly, both on mobile and desktop.

But there is one exception.

There is one scenario, where our PO got an crash, when he try to use ANY zoom functionality of the component. 

He is using:

• a Samsung Galaxy S21 FE 5G
• Android 14
• Chrome Browser

Steps to reproduce
Reproducible with UI for Blazor, as well as UI for ASP.NET Core (PDF.js and DPL processing)

1. Open the attached file in the PDFViewer.

Actual Behavior
The content is visualized distorted, large parts of it are missing, layout is messed up.

Expected Behavior
The document content is visualized properly, as it is with: https://mozilla.github.io/pdf.js/web/viewer.html

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; }
}

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.

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.
   

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.

I use TelerikPdfViewer to let my users annotate PDF documents (highlights, text boxes, drawings). Since the component only provides a built-in Download button (client-side) and not a Save to backend, I implemented a custom Save button that:

1. Calls await pdfViewerRef.GetFileAsync() to retrieve th e annotated PDF as byte[].
2. Sends the bytes to my server via a Blazor service call.
3. The server persists them to a file share with File.WriteAllBytesAsync(path, bytes).

Simplified:

<PdfViewerToolBarCustomTool>
    <TelerikButton OnClick="@SaveAnnotationsAsync">Save</TelerikButton>
</PdfViewerToolBarCustomTool>

var annotatedPdf = await pdfViewerRef.GetFileAsync();
await _scanFlowApi.SaveAnnotatedDocumentAsync(documentId, annotatedPdf);
// server-side: await File.WriteAllBytesAsync(path, annotatedPdf, ct);

It works — the annotations are saved and I can reopen the file in the viewer without issues. But after saving and opening the file in Adobe Reader, closing it shows the prompt "Do you want to save the changes made to this document?" — even though the user hasn't modified anything in Adobe. The PDF seems to contain incremental updates appended at the end.

The PDF Viewer uses adopted stylesheets, but removes third-party ones in the process.

This occurs since Telerik UI for Blazor version 7.0.0.

The workaround is to duplicate the third-party adoptedStylesheet as a regular CSS file.

Description

The byte array returned by the GetFileAsync method is different when the file is opened through the PDFViewer's toolbar, and when the file is loaded initially using the Data parameter of the PDFViewer.

Steps To Reproduce

1. Use the example below and the attached exemplary .pdf document.
2. Place a breakpoint in OnDownloadExportedFileClick
3. Run the example.
   Scenario 1: when the page loads and the attached file is loaded in the PDFViewer, click the button above the PDFViewer.
   Scenario 2: when the page loads, open the attached file in the PDFViewer, through the Open toolbar tool. Click the button above the PDFViewer.

@using System.IO
@inject IJSRuntime JSRuntimeInstance
@inject HttpClient HttpClient
@inject NavigationManager NavigationManager

<PageTitle>Home</PageTitle>

<p>
    <TelerikButton OnClick="@OnDownloadExportedFileClick">Get file with GetFileAsync and download</TelerikButton>
</p>

<strong>@TestResult</strong>

<br />
<br />

<TelerikPdfViewer @ref="@PdfViewerRef"
                    Data="@PdfViewerData"
                    AnnotationMode="@PdfViewerAnnotationMode.EnableForms"
                    Height="400px">
</TelerikPdfViewer>

@code {
    #nullable enable

    private TelerikPdfViewer? PdfViewerRef { get; set; }
    private byte[]? PdfViewerData { get; set; }

    private string TestResult { get; set; } = string.Empty;

    public async Task OnDownloadExportedFileClick()
    {
        var result = await PdfViewerRef.GetFileAsync();

        TestResult = $"First PDF Viewer GetFileAsync() returned {result} at {DateTime.Now.ToString("HH:mm:ss")}";

        var base64String = Convert.ToBase64String(result);
        var dataUrl = ToDataUrl("application/pdf", base64String);
        _ = SaveFileAsDataUrlAsync("export.pdf", dataUrl);
    }

    private protected ValueTask SaveFileAsDataUrlAsync(string fileName, string dataUrl)
    {
        return InvokeVoidAsync("saveFile", fileName, dataUrl);
    }

    protected virtual ValueTask InvokeVoidAsync(string methodName, params object[] args)
    {
        try
        {
            return JSRuntimeInstance.InvokeVoidAsync($"TelerikBlazor.{methodName}", args);
        }
        catch (Exception)
        {
            return default;
        }
    }

    private protected string ToDataUrl(string mimeType, string base64String)
    {
        return $"data:{mimeType};base64,{base64String}";
    }

    protected override async Task OnInitializedAsync()
    {
        PdfViewerData = System.IO.File.ReadAllBytes(@"pdf-viewer-form-filling-original.pdf");
        await Task.Delay(1);
    }
}

pdf-viewer-form-filling-original.pdf

Actual Behavior

The breakpoint in OnDownloadExportedFileClick is hit. Observe the difference in the byte array returned by the GetFileAsync method and saved in the "result" variable:

Expected Behavior

The byte array should be identical, regardless of the method of opening the file in the PDFViewer.

Browser

All

Last working version of Telerik UI for Blazor (if regression)

No response