PdfViewer GetFileAsync (always) returning NULL

[David Cresswell]

Hi,

I'm getting on quite well with TelerikPdfViewer. But now I'd like to access a form filled PDF and save it. 

I can see that the GetFileAsync function is meant to get me the current state of the file and have already noted that it... 

"Returns null if no document is loaded."

However, the document definitely is loaded. I'm looking at and I can even see it's properties are loaded when I debug it. I've even tested with & without a Rebind(), just for good measure.

I can also access the originally loaded Data property but, inevitably, this doesn't contain the form changes

Am I missing something obvious?

Following my most recent and only other post, rendermode is definitely InteractiveServer

Thanks

David

[David Cresswell]

Here is an example REPL in case it helps...

https://blazorrepl.telerik.com/QJEDRElo492eRPg145

[Dimo]

Hi David,

Frankly, at first I thought I was crazy too. Unfortunately, your observation is correct - the method does not work. I am truly sorry about the confusion and the missing feature.

The Blazor PDF Viewer depends on a home-grown JavaScript package, which in turn depends on PDF.js. My assumption is that something changed on the JavaScript side after we implemented the feature in the Blazor component and it broke the integration. The second puzzling bit is that you are the first one to report the problem.

I already logged a bug report on your behalf and awarded you Telerik points. I already notified the developers and I hope there is some minor oversight in the code that is easy to fix.

Regards,
Dimo
Progress Telerik

[David Cresswell]

Dimo,

Thank you for the thorough feedback.

I take it a workaround with older versions of this and/or PDF.js is not an option?

The bug report is also welcome development. Although, given how many other Unplanned ones there are, where should I be setting my expectations in terms of timescale for a fix?

Regards

David

[Dimo]

Hi David,

You are right that rolling back to an older version is not applicable in this case.

Given the nature of the bug, we will fix it with a higher priority rather then follow standard prioritization algorithms. We are already looking into it. So I would say that the next planned release in November may resolve the problem.

[David Cresswell]

Dimo,

Ok, thanks.

The November timescale may give me a problem with an increasingly urgent project requirement. I don't suppose there's any chance of a more incremental hot-fix, or even a more personalised workaround that might avoid me needing to source an alternative component?

Regards

David

[Dimo]

Hi David,

It turns out the problem is not that straight-forward to fix. We can release a new product version sooner than November, but we will need at least a few more weeks to investigate and resolve the bug. I am afraid I cannot commit to a specific time frame at this point, which I realize puts you in a touch situation. Sorry about that.

[Dimo]

@David

I am glad to inform you that the problem is resolved and we can release a fix soon, for example, in one or two weeks. We just need to check if something else urgent needs to be included. Is this OK for you?

[David Cresswell]

That's good to know and I appreciate the feedback.

Yes, that timescale should be manageable, although let's hope for something closer to one than two ;o)

[David Cresswell]

Dimo,

Sorry, for the slow response. I hadn't spotted last weeks release of 11.2.0 until just now, so have just been quickly re-testing.

I've updated my solution, but can't obviously notice any difference.

I've done likewise for the example REPL (https://blazorrepl.telerik.com/QJEDRElo492eRPg145), but that too shows no difference. Am I being stupid?

Regards

David

[Dimo]

Hi David,

Hmmmmm. This bug is creating a perfect storm on our side and probably gray hair on my head:

• There seems to be an issue in our release pipeline. We have somehow published version 11.2.0 with some outdated bits of source code, so this specific fix was not included. That's why, please upgrade to 11.3.0, which we released a few minutes ago. I confirm that the PDF Viewer GetFileAsync() method works with your REPL test page, which I updated. The previous REPL test page is not using the latest version - notice the orange dot in the left navigation.
• The GetFileAsync() method still returns null if the component does not load a file by default and the user opens a local file from their device first. I opened a new bug report about this on your behalf.

Please excuse us for this hassle. We still need to research the scenario with an initially empty PDF Viewer and what happened with the previous release, as it's rather peculiar.

[David Cresswell]

Hi Dimo,

Sorry, for the grief you are experiencing as a result of my post. I fear this latest instalment is not going to ease the pain.

I can confirm that 11.3.0 behaves differently to earlier versions and does indeed now work for my trivial REPL example. Equally so when I use that same PDF in my development project.

However, with almost all other attempts, the GetFileSync() call disappears into an endless holding pattern before returning "A task was canceled." (timeout?) exception.

I thought initially it might be triggered by PDF's containing form fields, but now I'm not so sure. I suspect, more probably, it relates to the size of the PDF. I have an example file of 34Kb that fails and a 5Kb one that works, so possibly an internal buffer of around 10K? 

But essentially, I can't get anything other than tiny files to work at all

Sorry

David 

[Dimo]

Hi David,

Most probably you need to increase the max SignalR message size in your app.

[Dimo]

We also fixed the problem with a null return value when the PDF Viewer is initially blank. Now I have the following questions:

• Are you affected by the issue, or your use case involves loading a default PDF file in the component?
• If you are affected, can you wait until our mid-November release?
• If you can't wait, are you OK if we send you a custom build, so that we don't have to publish a full new release?

[David Cresswell]

Dimo,

Ah, yes, max SignalR was indeed the issue.

Should the byte array, being returned, require any additional processing before saving as a valid PDF? The reason I ask is that my initial test seem to be saving as corrupt PDF's. On closer inspection (through Notepad++), I can see that the saved PDF seems to contain 30 or so bytes before the anticipated "%PDF-1.6" sequence.  Within those 30 bytes is the legible text "JS.ReceiveByteArray".

Whilst you might suspect the way in which I am saving the file (actually to Azure storage in my case), I can see those characters in the byte[] being returned...

https://www.dropbox.com/scl/fi/2dbnb03taaf28zf8y8pew/Telerik_debug.png?rlkey=o2ttyw07psg7cdhfus4we0sga&st=3bfgvi1y&dl=0

In terms of your second query, I've not obviously been affected by that scenario, so don't worry about it 

[Dimo]

We see the appended string and we see where it's coming from. The interesting part is that we are able to open the modified PDF file with web browsers, Adobe Reader, and the PDF Viewer itself. In other words, we don't get any client complaints about a corrupt PDF file.

So in order to verify the fix, can you please:

• Specify which PDF client are you using?
• Send us a file that is corrupt and doesn't open? You can also send us the non-corrupt original version.

[David Cresswell]

I hadn't thought to try a browser to view the PDF's, but can see that does indeed work. 

Prior to that, I'd tried and failed with my current preferred (Windows) viewer PDFGear. Although, having just tried Adobe, I can see that that also works. Maybe it is a PDFGear problem.

https://www.dropbox.com/scl/fi/v57kvrd8kd06oy6klaspz/example_pdfs.zip?rlkey=urjcif339tgp2khy5jifd6n3u&st=7pi42xiv&dl=0

Here are examples of your own form, the naming of which should be self-explanatory? All open fine (even with PDFGear) except for original_form_with_some_interaction.pdf

[Dimo]

Thanks. Indeed, I am not able to open the "some_interaction" file with PDFGear, however, it looks like the problem is not caused by the prepended "JS.ReceiveByteArray" string.

• If I remove the string, the file still doesn't open.
• If I try to open other files with PDFGear that have the prepended string, they open fine.
• If I fill in the PDF form and download / export it with the PDF VIewer, the resulting file has the prepended string and still opens.

So it seems we are missing something here?

[David Cresswell]

In addition to removing the first 31 bytes, You may also need to deduct the same amount from the checksum just before the EOF?

Is it possible that PDFGear are super strict about such things where as Adobe is less so?

[Dimo]

Not sure about PDFGear. It's possible, but this doesn't explain the second and third bullet from my previous reply.

In any case, we will consider removing this extra string, but some more devs need to take a look at the code change and approve it.

[David Cresswell]

I don't know enough about the PDF standard to really comment. What, if anything, does the extra string bring to the party, or is it just irrelevant bubble-wrap around the main payload? It maybe best to let your devs have their say.

In the meantime, I've sent a note to PDFGear with my earlier Dropbox link. Whether they'll respond is a different matter.

[Dimo]

Yes, I'd say the extra content is unnecessary and may even be there by mistake.